Robert Osfield wrote:
Hi Paul,
On Mon, Jun 2, 2008 at 1:23 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
Doing a diff between the 2.4 and current SVN headers it seems the API
changes that break things are minimal:
...
So porting from 2.4 to 2.6 (when it comes out) should be fairly easy, unless
you do deep stuff with database/terrain paging.
Indeed, even these API changes are unlikely to affect the majority of
users. In fact
the 2.0 to 2.2 to 2.4 to the eventual 2.6 are all likely to be
relatively painless ports.
What would be the exact premise for a 2.4 series? Keep the API stable, while
only providing bug fixes now and then?
This would be the rough plan - to keep a stable API, and if possible
binary compatible
too where possible, and just make stable releases when particular
fixes are really needed, it might be that the maintainer will just
declare some fixes as ones that will be dealt with by the next major
point stable release.
New features I would not expect to be something to roll into stable
release series, it might be occasional that a bug fix comes with a new
feature or change in a feature in which case the maintainer will just
have to show some discretion.
The aim should be to help users that require stable releases, wishing
to avoid the need for open ended porting to new versions - at most an
upgrade to a stable minor point release should be a recompile of the
OSG and their app, this is something that needs to be done
consistently so users needn't worry about extra porting work coming
about due to these extra releases.
Would there be a single stable branch and one development one? I.e. when
2.6 would come out it would supersede 2.4?
What about additions, like new
examples (e.g. osgscreencapture), CMake 2.6 support, threaded HTTP fetching
of models? Browsing a bit through the SVN log I think the number of fixes to
backport at this point is relatively minor. But backporting for example
support for CMake 2.6 might be a bit too much, though (haven't looked at it
in detail). The amount of maintenance is therefore directly linked to what
you expect a stable branch to contain compared to the development code...
It's support for CMake 2.6 which is one of the motivations for make a
2.4.1, as well as the bug fixes.
In terms of making a 2.4.1, we could either use SVN trunk as the
source and not bother back porting, or do the job by back porting to
2.4. Just taking SVN would be quicker and less initial work, but it'd
introduce new features into the bag that haven't been tested
thoroughly yet, but then there is always 2.4.2 to fix all the problems
in 2.4.1 ;-)
Hmmm, that kind of defeats the purpose of making a 2.4.1 release, if
it's actually just 2.5.1 with a different number, as that _would_
include (minor) API changes.
If I were to tag a 2.4.1 right now I'd just use SVN as I don't have
the time to review all the different changes and back porting them to
2.4.
But that doesn't really solve this on the long term, does it. To be able
to have easily manageable stable branches would mean branching the trunk
just before a new minor stable release and then backporting fixes and
small additions from the trunk to work up to each new point release on
the stable branch.
Paul
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
