Hi Guys, Now that I've decided to go for 2.0 for the next stable release of the OpenSceneGraph, I have started thinking about the run up to 2.0. I want 2.0 to stable and well tested, this will required testing and debugging at my end, by developers who use SVN day to day, and it'll require a series release candidates that are tested as widely as possible. I do wonder about an alternative strategy though, I now think its time to adopt Odd/Even versioning of the OpenSceneGraph. Here's a few of the issues/motivations:
In the past we've named the release candidates as things like 1.2-rc1, 1.2-rc2 etc. This is OK, but a little awkward. It also forces the issue that these release candidates are tightly coupled to the target version number, but also in a odd way diverging from it, rather converging towards it. Originally I wanted point releases to get back to the old 6-8 week cycle, but alas I've been swept off my feet with work this last year so this cycle has soundly broken down. Development work has tailed off, the OpenSceneGraph software itself is still roaring ahead. Due to my workload I haven't had a quiet time to push forward on a stable release - I haven't had a spare day, let alone a month+ required to get stable release out. End users still need to get their own software out the door, and basing this on SVN version really isn't great - end users need releases more often, ideally fully tested and ground out, but I'd guess a developer release would be better than a SVN snapshot. Another datapoint was something we discussed at the Highland Gathering back in October - that we makes for calls of testing of release candidates, and people do come forward and help out with testing, but the numbers has not increased over the years, despite the community size being massive bigger, if anything less volunteers get stuck in. We are all busy so this is understandable, but... the downside is that the less testing release candidates get exposed to the less problems we'll spot. With most releases we see simple to fix problems turn up almost immediately after a release, simply because one platform, or build combination, or certain class wasn't tested. This is really frustrating, but how to fix it... One is get more people using the SVN version, the other is to get more releases out the door so those who don't want to dabble with SVN version version can get stuck in... Could a developer point release be a good half way house between SVN and formal stable releases? I now feel this is the way to go, have developer releases go out regularly and steadily work towards the next stable release. A common convention used by other open source projects is to name all developer releases as ones with odd point numbers, and stable releases with even point numbers. So 1.2 is stable, 1.3 developer, 1.4 stable etc. In the past I didn't go for this as I felt that we had stable releases going out often enough that developer releases weren't appropriate. For the past year this has held up though, we have had way too long between stable releases that end users do need some point in time to base their software on. Introducing Development releases seems a good solution. So, this morning I bit the bullet, and updated the SVN's version numbers to 1.9, as the development release for the up coming 2.0. I don't know how soon 2.0 might be, but we can tag 1.9 and just stick it out there as source code pretty quickly. Every couple of weeks we can put out another development source code snapshot. I'd suggest we do a call for testing of SVN on the main Windows, Linux and OSX platforms and if it builds and runs OK just tag it and putting it out as a development release. I'd hope that it'd only take a day or two to turn around a development release, the quicker we can turn them around the more often we can make them. Another side effect of development releases is that release candidates can just become minor point releases on a development version, i..e 1.9.1, 1.9.2 etc and steadily converge to 2.0, when we have a development release that is good enough, when just bump the version number to 2.0 and then go build binaries etc. Hope this makes sense for you all :) Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
