Re: [Flightgear-devel] Version number for the upcoming release
On Monday 14 December 2009 05:46:11 Chris Wilkinson wrote: There could have been any number of better ways to express the version number, but they chose to use one that can combine more than one decimal place into what looks to a lay person like a mistyped number... not clever. Well they chose major and minor version numbers delimited by a dot, which can and is easily extended to even finer granularity by just adding another group or two. It's certainly no perfect system, but it's been adopted in practically the whole computer industry, software and hardware. So FlightGear is in fairly good company there. The chances that someone would misunderstand this universally adopted scheme are quite small if you ask me. People seem to cope with it quite well, as they do with IPv4 addresses which are usually written as four groups of numbers seperated by the same dot: 123.45.67.089 And anyway: here in Europe (except for the UK and Ireland), we don't even use a dot as decimal separator. We use the comma while the dot is used for grouping thousands. And it's the same in many other parts of the world, for example South America. So what's wrong again with using the same system that just about everyone else uses? Stefan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
I don't think anything wrong with the MAJOR.MINOR.PATCHLEVEL format, I think it's fairly obvious, and is widely used. I'm not a huge fan of rolling over into double digits though, unless you started with double digits to begin with. For example 1.09 to 1.10 is logical to me, but 1.9.1 to 1.10 is not, I would expect 1.9.1 to be the newer in this case. Perhaps it is time to go to 2.0 then, in hindsight osg should have probably been 2.0 being such a major change in direction. Being 2.0 can also give some leeway to excuse the bugsI mean hey, we're in the infancy of a new major number release...of course there are flaws. :D :D cheers! --Jacob -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
Hi there, The chances of people in this mailing list misunderstanding that convention are low, because by and large we're advocates of free software which is predominantly released under such numbering schemes, but I feel confident I could take that convention around the engineering office I work in and confuse a whole lot of otherwise very intelligent people. The (un)washed masses are used to titles such as 'Office 2007', 'Word 2003', and dare I say it, 'Flight Simulator 2004'. Those names give some kind of meaning, whereas Flightgear 1.9.2 to a lay person (no matter how intelligent) probably would not mean a lot. FG to me is more developer-driven than user-driven, and I would also think devs make up a significant proportion of the user base. Devs would be more likely to be using cvs than stable 1.9.1 as their daily tester/flyer. So long as cvs keeps working the way it does I cannot see any problem with keeping the scheme intact for development, but simplifying the fg name a bit for major releases, since that only happens pretty much annually. How about 'Flightgear 2010' for the next stable release? Might spark a bit more user interest in the project by having a more human name for milestone releases... Just my $0.02 worth again... Regards, Chris Wilkinson, YBBN/BNE. From: Stefan Seifert n...@detonation.org To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Mon, 14 December, 2009 6:40:32 PM Subject: Re: [Flightgear-devel] Version number for the upcoming release On Monday 14 December 2009 05:46:11 Chris Wilkinson wrote: There could have been any number of better ways to express the version number, but they chose to use one that can combine more than one decimal place into what looks to a lay person like a mistyped number... not clever. Well they chose major and minor version numbers delimited by a dot, which can and is easily extended to even finer granularity by just adding another group or two. It's certainly no perfect system, but it's been adopted in practically the whole computer industry, software and hardware. So FlightGear is in fairly good company there. The chances that someone would misunderstand this universally adopted scheme are quite small if you ask me. People seem to cope with it quite well, as they do with IPv4 addresses which are usually written as four groups of numbers seperated by the same dot: 123.45.67.089 And anyway: here in Europe (except for the UK and Ireland), we don't even use a dot as decimal separator. We use the comma while the dot is used for grouping thousands. And it's the same in many other parts of the world, for example South America. So what's wrong again with using the same system that just about everyone else uses? Stefan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/-- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
What if we start naming releases in addition to the normal version scheme. FlightGear 2.x.x name, name could be some continued variation on a theme or something. I think that would be a nice middle ground, we keep a meaningful versioning scheme, and also get a catchy name for everyone. I've worked on projects that have done this and it works well I think, the name usually changed for every meaningful release1.1, 1.2, .1.3...etc. cheers --Jacob -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
On Mon, Dec 14, 2009 at 10:09 AM, Jacob Burbach jmburb...@gmail.com wrote: I'm not a huge fan of rolling over into double digits though, unless you started with double digits to begin with. For example 1.09 to 1.10 is logical to me, but 1.9.1 to 1.10 is not, I would expect 1.9.1 to be the newer in this case. Lexical sorting too, which can be a nuisance in version checks or directory listings. -- Csaba/Jester -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
Hi, On Dec 14, 2009, at 7:18 AM, James Turner wrote: One observation - the intention, at least mine and Tim's, is to move to quarterly releases, so I have no intention of 'finishing' the route manager for a particular release. (Regular release cycles take the pressure of rushing to complete a feature) Stable features will be integrated onto the 'next' branch, when they're complete (or a functionally useful subset is complete). The shaders and sound changes both fall into this category, while the route manager work is certainly not in that category yet. I vote to both quarterly release and separating stable branch from development branch. My opinion about next version number is 1.10.0 since the current FG doesn't reach the 2.0 criteria (We stil miss shadows). I would accept 1.19.0 if we agree that our effort in this year worth 10 times of minor updates. Anyway, we must not go for 2.0 unless we change the 2.0 criteria. Tat p.s. Though 1.10.0 can be confusing (or using dots is confusing), you can get used to it when you know how the versions numbers are compared. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Version number for the upcoming release
Hi All, About this point in the release cycle, it's traditional to have a version numbering discussion, if only so Martin and I can ensure that the documentation matches the final binary! My thoughts are as follows: - The changes we've made in the last year are significant, so incrementing from 1.9.1 to 1.9.2 seems inadequate, given that the increment from 1.9.0 to 1.9.1 was a bug-fix release. - Changing from 1.9.1 to 1.10.0 is going to confuse at least some people (though we've done it before with 0.9.10). As I recall, the original argument for not naming the last release v2.0 was that we felt that there were still some plib features that we didn't have in OSG, in particular shadows. However, the graphics in OSG now exceed plib in most areas (better 3D clouds, trees, shader effects, multiple camera support), so I would claim that this is no-longer a sensible comparison. Given this, I think we should just bite the bullet and go for v2.0.0. We should be pretty proud of the scope and function in FG, and I think that is an appropriate way to recognize this. If we start making releases on a more regular basis, this would also allow us to use major version numbers annually (v3.0.0, v4.0.0), and minor version numbers (v3.1.0, v3.2.0) for more quarterly releases. -Stuart (There, that'll increase list traffic...) -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
Hi there, The changes to fg in the past 12 months are very significant and welcome, but the implementation of some of the changes is still in its infancy. That factor, along with the missing shadows, leave me feeling that an update to v2.0 is not yet warranted - not quite! Its getting close, but to me requires a little more polish. Going to 1.9.2 wouldn't do justice to all the work done since 1.9.1, so 1.10.0 would get my vote. The missing shadows would *have* to be reimplemented for me to feel like the software deserved a v2.0. After all, to add something that significant in the earlier versions, then have it vanish (understandably of course, the 'engine' got replaced after all!), then not see it return, is slightly disappointing. Thats my $0.02 worth. Regards, Chris Wilkinson, YBBN/BNE. From: Stuart Buchanan stuart_d_bucha...@yahoo.co.uk To: FlightGear Dev flightgear-devel@lists.sourceforge.net Sent: Mon, 14 December, 2009 7:02:14 AM Subject: [Flightgear-devel] Version number for the upcoming release Hi All, About this point in the release cycle, it's traditional to have a version numbering discussion, if only so Martin and I can ensure that the documentation matches the final binary! My thoughts are as follows: - The changes we've made in the last year are significant, so incrementing from 1.9.1 to 1.9.2 seems inadequate, given that the increment from 1.9.0 to 1.9.1 was a bug-fix release. - Changing from 1.9.1 to 1.10.0 is going to confuse at least some people (though we've done it before with 0.9.10). As I recall, the original argument for not naming the last release v2.0 was that we felt that there were still some plib features that we didn't have in OSG, in particular shadows. However, the graphics in OSG now exceed plib in most areas (better 3D clouds, trees, shader effects, multiple camera support), so I would claim that this is no-longer a sensible comparison. Given this, I think we should just bite the bullet and go for v2.0.0. We should be pretty proud of the scope and function in FG, and I think that is an appropriate way to recognize this. If we start making releases on a more regular basis, this would also allow us to use major version numbers annually (v3.0.0, v4.0.0), and minor version numbers (v3.1.0, v3.2.0) for more quarterly releases. -Stuart (There, that'll increase list traffic...) -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7. Enter now: http://au.docs.yahoo.com/homepageset/-- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
Traditionally it is MAJOR.MINOR.PATCHLEVEL, definately more than a patchlevel thing, and way more than minor, so either 1.10.x or 2.x.x if your following that standard. 1.10 feels weird, but not sure 2.x is warranted just yet. Could ditch all that and use dates ala ubuntu, making it what...like 12.9? :D But, are we really going to try and rush the release out by years end? Nan errors still abound, sound system has lots of rough edges still, the new material system is not finished, route manager not finished, etc, etc. Even if everything could be cleaned up by then, there would be no time left for any real testing/bug fixing. Seems like a bad idea to me. Or would it be a release candidate type thing? Has development even been frozen and branched yet? cheers! --Jacob -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
On 13 Dec 2009, at 22:10, Jacob Burbach wrote: Nan errors still abound, sound system has lots of rough edges still, the new material system is not finished, route manager not finished, etc, etc. Even if everything could be cleaned up by then, there would be no time left for any real testing/bug fixing. Seems like a bad idea to me. Or would it be a release candidate type thing? Has development even been frozen and branched yet? One observation - the intention, at least mine and Tim's, is to move to quarterly releases, so I have no intention of 'finishing' the route manager for a particular release. (Regular release cycles take the pressure of rushing to complete a feature) Stable features will be integrated onto the 'next' branch, when they're complete (or a functionally useful subset is complete). The shaders and sound changes both fall into this category, while the route manager work is certainly not in that category yet. Bug-fixing, testing, etc is of course a separate issue - namely that fixing bugs is a lot less fun than writing features. James -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
Bug-fixing, testing, etc is of course a separate issue - namely that fixing bugs is a lot less fun than writing features. As a developer I certainly won't disagree with that, but they are an absolute necessity for any software, it just comes with the territory. As a user I would also say a stable release is a lot more fun than a half finished, buggy one. ;) cheers --Jacob -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
Jacob Burbach wrote: Traditionally it is MAJOR.MINOR.PATCHLEVEL, definately more than a patchlevel thing, and way more than minor, so either 1.10.x or 2.x.x if your following that standard. 1.10 feels weird, Maybe it is wierd. 1.9 is mathematically the same as 1.90 1.10 is less than 1.90 by any normal math or sorting formula. Just my 2 cents. Stewart -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
Hi there, Whoever decided that software versioning should follow such a numbering convention is a goozer, and you can quote me on that! :-) There could have been any number of better ways to express the version number, but they chose to use one that can combine more than one decimal place into what looks to a lay person like a mistyped number... not clever. Maybe something like 'Flightgear 2 Beta 1', or Flightgear 2 Beta 2009-12-14, or even something not using the decimal point as a separator like 1:10:0 would be an improvement? It has always been something about many softwares that I've disliked, is that they use the x.y.z numbering scheme. Regards, Chris Wilkinson, YBBN/BNE. From: S Andreason sandrea...@gmail.com To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Mon, 14 December, 2009 1:07:12 PM Subject: Re: [Flightgear-devel] Version number for the upcoming release Jacob Burbach wrote: Traditionally it is MAJOR.MINOR.PATCHLEVEL, definately more than a patchlevel thing, and way more than minor, so either 1.10.x or 2.x.x if your following that standard. 1.10 feels weird, Maybe it is wierd. 1.9 is mathematically the same as 1.90 1.10 is less than 1.90 by any normal math or sorting formula. Just my 2 cents. Stewart -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7. Enter now: http://au.docs.yahoo.com/homepageset/-- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
On Sun, 2009-12-13 at 19:07 -0800, S Andreason wrote: Jacob Burbach wrote: Traditionally it is MAJOR.MINOR.PATCHLEVEL, definately more than a patchlevel thing, and way more than minor, so either 1.10.x or 2.x.x if your following that standard. 1.10 feels weird, Maybe it is wierd. 1.9 is mathematically the same as 1.90 1.10 is less than 1.90 by any normal math or sorting formula. Version identifiers are not numbers, they are often stored as strings, the period is just a delimiter. Software version naming schemes are many and varied, and once the marketing department get involved all reasonable and rational numbering schemes go out the window, hence we have Office 2003 that was released in 2004, Oracle 11g Application Server is actually 10.3.1 etc etc etc I used to work for a company called Digital Equipment Corp. the version identifiers were prefixed by a letter which indicated it's level of release (ie: was it a fully released product). Also the even numbered releases (eg: V1.2, V1.4, V2.2, V2.4, V2.6) were for new feature releases, the odd numbered ones where mainly for bug-fixes. So a bit of code could started life with the letter 'X' for experimental,or just start with 'T', then when it was doing an internal beta (field) test it started with 'IFT' or 'EFT' if external customers involved, and then finally the letter 'V' once customers could pay for it. There were a few other letters at various stages of release, but I can't remember them all. The version number part was major.minor and then if there was a patch that was added after a hypen, and then sometimes an update to a patch with a single letter (ie: A then B, then C etc) and also for some software there was a Baselevel number, the baselevel was a grouping of functionality, so for example you have some software where there is a slow meeting of functionality over actual version releases (for example the Route Manager/GPS code could release a base level of functionality for 1.10.0 and then more functionality for 1.12.0 and then even more functionality for 2.0.0, so these could be marked with BL1, BL2 and BL3) So versions would like; V1.1 T2.0 BL2 IFT1.3-5 Generally a major version number change is only for architectural changes, rather than the level of completeness, so we could have gone to V2.0.0 when moving from PLIB to OSG, even though all the functionality wasn't implemented, and you may well reach the level of all functionality being implemented in V2.5.0 and then moving V3.0.0 once it was stable. Some folks change the major version number once they have actually implemented the functionality they set out to implement in hand full of version changes (eg: V1.0, V1.1, V1.2, V2.0, V2.1, V3.0 etc). There is really no hard and fast rules, but you should be consistent to help users understand what they can expect in a release of software, small changes, big pain, new features, it also helps to work out dependency, V1.10.0 requires Foobar V3.9.0. Anyhow I vote for V1.10.0 it makes sense, to stay consistent, since it didn't go to V2.0.0 with the architectural change to OSG. S. ** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ** -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
