Robert, I am a little reluctant to respond to this as I think my response could set off some flames, but I thought I would go ahead and do so with the caveat that this is only my opinion.
I think what you are proposing here sounds like a bad idea. Rushing a major release like this so that it won't conflict with a book seems to be putting the cart before the horse. It is okay for the book to talk about things that are not complete yet. What is the issue with that? The book can merely address items as they are proposed to be done and not get bogged down with "in this development release" and so on. Any document of a software project that is in a state of development should (and usually does) have a paragraph in the introduction which says something to the effect of "this work was based on release blah-blah-blah". That could certainly be done here and then all awkward language in the main text is obviated. Of course this really wouldn't concern me if you were only talking about releasing 2.0 with some minor features missing, but I think you would have to admit that osgViewer is a fairly major feature (as is osgTerrain for many users). What I THINK would be a better idea would be to let the book release when it does, assuming that the missing features and functionality will be there as designed. Then, finish the features for the 2.0 software release as scheduled, getting the features in place that you had originally intended. That way there is not a rush to release and it can be done right with all features in place and 2.0 will only lag behind the book by a couple of weeks. Again, just my opinion... -- Paul On Friday 18 May 2007 09:32, Robert Osfield wrote: > Hi All, > > I have exchanged emails with Paul Martz about getting 2.0 out in time > for his publishing on the Quick Start Guide, should be out in the > first week of June with a final draft before this. > > So this gives 2-3 weeks to get 2.0 out the door. Yikes you might > think, and rightly so ;-) > > First up I have to say that I'd like now we have weekly dev releases > going out, without too much overhead at my end (takes about a hour of > my time), doing minor point releases for stable versions should not be > so daunting as it was. I we can make minor point releases more often, > then having one that is not quite perfect is much less of a worry - > since another one will come out shortly after to fix any problems that > arise. > > The real difference between a dev release and stable release is a bit > more testing in the run up, the production of binaries, and the > updating of docs on the website. I can't do most of this myself, > I'll need members of the community to pitch in with testing, producing > the binaries and help get the web pages updated. Also the more > streamlined we can make all of this, the quicker and more often we can > get releases out. At least that the theory.. > > Due to this quick time frame I simply won't be able to complete all of > functionality that I wanted for 2.0, such as osgViewer, osgShadow and > osgTerrain work, this is shame, but I'd now rather have a 2.0 out in > time for the book to go, and to keep the book straight forward in > terms of referencing 2.0 binaries and source cde - otherwise you'll > end up with a book talking about something that hasn't come out yet, > and binaries that don't exist, or it ends up bogged down talking about > dev releases. > > Overall my impression is that the 1.9.x dev series have been pretty > stable, a few hiccups here and there on build and execution, but my > guess we are well in the same ballpark as the quality of 1.2, and in > many areas I know it far exceeds that of 1.2 since we've made so many > bugs fixes over the past 8 months. > > For the loose ends we currently have, I'd say lets log them, try and > fix them for 2.0, but if we can't just push ahead get 2.0 - just make > sure there is no show stoppers on the main platforms. Any remaining > loose end we can scoop up after 2.0 with 2.0.1, 2.0.2 etc releases. > > I look forward to feedback and your assistance. In particular we need > volunteers to build binaries on the 3 main platforms - Windows, Linux > and OSX. > > Thanks in advance, > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
