Board index FlightGear The FlightGear project

the way each version is numbered is confusing

Questions about the FlightGear organisation, website, wiki etc.

the way each version is numbered is confusing

Postby Steve78 » Mon Feb 25, 2013 7:40 pm

The newest version is 2.11, as in two point eleven. The previous version was 2.8, as in two point eight. Most people see the number 2.8, they think 2.8 is newer than 2.11.

It can be less confusing if you use a two-digit number after the decimal point, like 2.08 instead of 2.8. When you release the next version, how about calling it version 3.01, and then 3.02......3.03.........3.04?

EDIT: Some people see 2.11 and they think it is two point one one, not two point eleven.
Last edited by Gijs on Mon Feb 25, 2013 8:07 pm, edited 1 time in total.
Reason: Please edit your post if you have more to add, shortly after posting.
Steve78
 
Posts: 18
Joined: Thu Dec 27, 2012 7:24 pm

Re: the way each version is numbered is confusing

Postby Thorsten » Tue Feb 26, 2013 6:46 am

Most people see the number 2.8, they think 2.8 is newer than 2.11.


How do you know what most people think when they see this? Did you make a survey? The fact that none of the people reading the devel list and no one in the forum except you mentioned any problem would indicate to me that most people interpret 2.11 as later than 2.8 and are aware that version counting schemes are not decimal numbers (there are versions like 1.9.1 around for instance which cannot be decimal numbers) and that only a minority of people jump to your interpretation.

I don't think it's a major issue - for developers it's important to have a labelling scheme regardless of how it works so that we can track what version a bug report refers to, users get the latest version from the Linux distribution of their choice or from the FG website and don't need to care about numbers.

And we can hardly go back and change 2.8 to 2.08 in any case. I think the convention isn't too bad - major version updates change the first digit, the 6 month release cycle changes the second digit, bugfix releases change the last digit, so the second bugfix update of the current version would be 2.10.2.
Thorsten
 
Posts: 10965
Joined: Mon Nov 02, 2009 8:33 am

Re: the way each version is numbered is confusing

Postby Hooray » Wed Feb 27, 2013 1:19 pm

Please see: http://wiki.flightgear.org/Release_plan#Version_numbers

PS: I have to admit, I recall FG version numbers being a little confusing in the beginning ... and we had a really hard time explaining that to other avsim users back when these forums didn't exist yet. So I can relate to *users* thinking that "2.8 must be newer/better/more recent than 2.11" (i.e. interpretation as decimals) - the whole major/minor concept is clearly irritating to people not familiar with software development and labeling schemes, which is why software is often versioned using code names or simply years: FlightGear 2013-1 or FlightGear 2013-2, FlightGear 2013-ALPHA or FlightGear 2013-BRAVO
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: the way each version is numbered is confusing

Postby curt » Wed Feb 27, 2013 4:55 pm

I have always considered version number schemes somewhat of a minor issue and have always been surprised by how passionate many people get about this; often more passionate than they are about religion, politics, operating systems, and text editors all put together. That really surprised me when I got hit upside the head by it.

I've always thought of version number schemes as a way to distinguish one version from the next. 1, 2, 3, ..., A, B, C ... but there are an infinite number of variations. Major, minor numbers, years, names with some sort of related theme, or random names even. I've personally never liked the random names because unless you are really involved in a project, you have no idea what's old, what's new, what's stable, what's development, etc. But people like branding I guess which is maybe why Fedora 18 is named spherical cow. People also seem to assign expectations to a product based on the way it's version number looks. Commercial companies realize this and try to leverage it to a competitive advantage (my version number is higher or better than your version number!) FlightGear doesn't compete commercially so we don't have to play dumb psychological games with consumers -- we could, we just don't have to if we don't want to.

When considering version numbers for my own projects I've always been tempted to use A, B, C ... just to be different. But then maybe that's just too different for most people to get a grip on. I look at all the various schemes and kind of chuckle in a light-hearted way. It's not a big deal to me in most cases as long as there are reasonably consistent rules we can explain to people.

I know people can line up and beat the flightgear developers over the head with all the reasons 2.10 doesn't make sense and you are all right -- you are explaining sources of confusion that are valid. But at the same time I can turn right back around and explain the logic of our numbering scheme to you. So there you go. If this confusion leads to a plague of asteroids hitting the earth, then I will humbly apologize on behalf of the entire FlightGear project. But I can point out that you can always go to www.flightgear.org and find the newest version.

Oh, one other thing I've learned -- maybe it's a piece of advice for other developers too -- never start out calling your first version 0.00 -- that is what we did with FlightGear and it was a ***HUGE*** mistake!!!! (I smile when I say that, see above explanation for a hint at why I am smiling.) The problem was that v1.0 means something to people. It means "finished". If your current version is < 1.0 you are not finished, and moving the version to 1.0 means you think you are finished. No longer is a version number simply a way distinguish one version from the next, now if you call your program 1.0 and it's not fully finished by everyone's definition of 'finished', you are liars, LIARS I say -- it's not finished! But the reality is that software is *never* finished. That's one of the very first things I learned when I started writing my first programs in basic on an Apple II.

Always, always call the first version number of your first release (even if nothing works yet) call it v1.0. That will save you a lot of headaches later. It will save you from being a LIAR and a FRAUD if you try to move from < 1.0 to 1.0 and some user doesn't think the code is ready to have full v1.0 honors bestowed upon it. Start out with v1.0 and everyone will love you. :-)

So right or wrong, for better or worse, my personal viewpoint is that version #'s are there to distinguish one version from the next. From my view point, exactly what scheme is chosen and how it's implemented is a pretty minor point as long as there are consistent rules, and even if there aren't fully consistent rules, this is still a pretty minor point for anyone to get too whipped up about.

Again, it's fine to point out possible sources of confusion or inconsistency, it's fine to discuss these things. I am discussing these things right now. But my hope is that people keep it all in context and save their passion and energy for more important things.
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: the way each version is numbered is confusing

Postby Hooray » Wed Feb 27, 2013 5:16 pm

curt wrote in Wed Feb 27, 2013 4:55 pm:The problem was that v1.0 means something to people. It means "finished". If your current version is < 1.0 you are not finished, and moving the version to 1.0 means you think you are finished.


All very valid points, but to make this issue a little more relevant and not just anecdotic: We are actually having the same issue now regarding "when" to release a 3.0 - as you undoubtedly know, because a number of core developers (and other contributors) have repeatedly raised the "FlightGear 3.0" discussion on the devel list.

So the accomplishment of switching from 1.x to 2.x and to 3.x still does mean something to many people, not just FG "outsiders" (or new users), but also long-term contributors, as was mentioned by Torsten on the devel list:

http://www.mail-archive.com/flightgear- ... 38888.html
Torsten wrote:To get to the 3.0 goal sometime in the near future, it's probably a good
idea to create a backlog of open items in the wiki and link the release
plan document to that.

As usual, we don't have to be perfect for a new major release number.
But the new features being the reason for the new major number should
work reasonably correct. I can't tell if that's the case for Rembrandt
as I didn't have the time for any tests over the last 12 month or so.


Which is why we have set up a wiki page to collect the 3.0 goals: http://wiki.flightgear.org/FlightGear_3.0_backlog
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am


Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 5 guests