At this point, I want to re-examine the rationale for a 1.2 release and make
sure it makes sense.
I had already started to remove some old deprecated code from osgWorks (Grid.h,
others) and osgBullet (ColladaUtils.h, others), with an eye towards a
non-backwards compatible 2.0 release. Then OSG put out back-to-back 3.0 and
3.0.1 releases. I feel some obligation to tag osgWorks/osgBullet releases that
are compatible with OSG v3.x. The problem is really one of naming.
Option #1: I could tag v1.2 releases now for compatibility with OSG3.
Unfortunately, they wouldn't be backwards compatible, even though this is
implied from the unchanged major version number.
Option #2: I could tag releases now and call them "2.0", and what we've been
calling v2 would be renamed v3 and come out later this year.
Option #3: Don't put out a release right now at all, just work towards 2.0
(probably later this year).
My preference had been for option #1, but now I'm starting to lean towards
option #3 -- if no one is screaming for OSG3-compatible releases, then I should
feel no obligation to put any out, and I'll just continue with plan and work
towards osgWorks/osgBullet v2.0, probably available later this year.
So if no one has a preference, I'll go with option #3.
--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/