Hi Paul, On Sat, May 31, 2008 at 9:47 PM, Paul Martz <[EMAIL PROTECTED]> wrote: > Why would this release be called "2.4.1" rather than "2.6"? In other words, > back when 2.4 came out, there was no question that it would be called "2.4" > as opposed to "2.2.1" -- what's different about this proposed release? > Example criteria: > - Is it binary compatible with 2.4? > - Is it bug fixes and new functionality only, no interface changes or > backwards compatibility issues with 2.4? > - Other criteria?
In an ideal world I'd suggest a 2.4.x series are all binary compatible. However, sometimes that is really hard to achieve as some bug fixes involve modifications the API to fix a bug. There are couple of such bug fixes in 2.5.x then come under this category. If one relaxes the strict binary compatibility for 2.4.x series then one is faced with the question how far do you relax it. I'd suggest that at most a recompile of the OSG and the client application should be required, and no code changes should be required. Another issue is that for a stable patch release we still have SO version numbers in place, so the issue of binary compatibility can be dealt with by bumping the SO version number, but... we also have the developer releases running in a parallel, and they also often bump the SO version number. Potentially this could lead to both stable and developer releases overlapping SO version when they aren't binary compatible. The solution to this is coordinate the SO version numbers so that they never overlap, but... this might lead to odd incrementing when SO version numbers are skipped. The other alternative would be to leave something like 10 SO version numbers around for 2.stable.x after each stable release and the first developer release that breaks compatibility would jump by 10, giving plenty of room of the 2.stable.x releases to goble up SO version numbers. For this particular release I'd be tempted to just be lazy and make 2.5.1 a release candidate of 2.4.1. There is quite a bit more functionality added/changed than I'd ideally like to see in a 2.4.x series, but the horse has somewhat bolted now, SVN trunk has all these fixes and extra functionality in it. The more thorough way would be to pick and choose which revisions make it from SVN trunk into a 2.4.x by back porting them to 2.4.0, doing things on a strictly fix needed basis. Perhaps in future stable release this could be done right away as part of the maintenance work that a stable series maintainer would take on. Of course one could not bother to do 2.stable.releases at all and just gun for the next stable release to add all these fixes into. However, since 2.0 we've had stable releases 3-6 month intervals, doing it much more often than 3 months would be challenge, as new functionality itself needs time to developed and shaken down. New/amendments to previous functionality also brings bugs, even bug fixes can bring bugs... so the first stable release often has a few new bugs, despite fixes a number of old ones. I believe on average we are fixing more bugs than we introduce in each stable release, but... we are still introduce new bugs each time... while not desirable it's just a fact of life with software, so having stable releases which sole purpose is to fix bugs and not introduce new functionality would be useful. Another aspect to the OpenSceneGraph development cycle is that while quite a few users do track SVN and developer releases not everyone does - many users wait till stable releases come out. This means that platforms and application usage models that aren't tested during the run up to stable release are suddenly tested after the the stable release is made, revelling bugs, often ones that could very easily have been caught given the wider testing, but still to late to help fix the stable release, so... these fixes then make it into the dev releases, and then the next stable release 3-6 months later, where exactly the same cycle happens - new problems that could have been fixed if we knew about them don't get fixed.... Ideally every platform and every usage model that the OSG is put through would be thoroughly tested all the time, so we wouldn't have the bug not caught, fixed to late for stable cycle, but no matter how many appeals for testing I make we never seem to close the gap enough to prevent problems not being detected. Having long testing periods before stable releases can help thing a bit by given more users a chance to test, but this makes release far more expensive and painful for myself and others helping out on testing them. If stable releases are too expensive/painful then they'll happen even less often, making it even more critical that no bugs are missed. But... it's impossible to get everyone to test, and to catch all issues no matter how hard you try so problems will always get through. Another factor that is apparent is with longer test periods before stable releases the more submissions that offer new functionality/amend existing functionality will start piling up in the queue waiting for the feature freeze period to pass. This makes the post release period for me particularly difficult - getting stable releases are already a bit like running marathon, but once its complete I suddenly have to deal with all these submissions that have been waiting for the stable release to go out, so its back to running a sprint almost immediately just to catch up and get back on top of things. This is what can cause burnout in myself, as well as put stress on contributors and general software development. What I'd like to see if the OSG development cycle to become further streamlined, with shorter periods before and after an initial stable release that lots of developers are putting in 110%. I believe having 2.4.x, 2.6.x etc stable release series could take the pressure of the initial stable release being quite so perfected, as if a 2.4.1 comes out a week or two after an initial 2.4.0 then end users using the stable releases will be in a better position, and those working on the 2.5.x dev series and towards the next stable release can get up and running on this right away. Perhaps one could even go further and have a 2.stable.0 branch made from the trunk prior to the official 2.stable.0 release, then the trunk immediately becomes a 2.stable+1.x series and the nominated maintainer takes over responsibility of the 2.stable.x series right from the initial branch. Thoughts? Robert. to overlap stable release so version number _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
