[Pkg-osg-devel] [Debian External Health System] openscenegraph: New upstream version available

Alberto Luaces aluaces at udc.es
Sat Apr 23 09:59:51 UTC 2011


"Manuel A. Fernandez Montecelo" writes:

> On Friday 22 April 2011 13:38:12 Alberto Luaces wrote:
>> Hello,
>> 
>> this is just a note to say that 2.8.4 is just a convenience release
>> mainly aimed at Visual Studio 2010 users, and doesn't implement any new
>> functionality from 2.8.3 as told in
>> 
>> http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/66596
>
> So do you mean that you vote for not shipping it in Debian?  I vote for 
> that, too.
>

Exactly.

>
> --
>
> On a side note, I find their release policy (and communication with users 
> via their website, I don't follow their mailing lists for quite a while) 
> somewhat annoying.
>
> For example, you mentioned months ago that they had planned a release 2.8.4 
> in august, and that did just happen now, 8 months later and just over a year 
> after 2.8.3 -- and with irrelevant changes.
>
> And I just saw that they mention in the website in news from December that 
> 3.0 is going to be released "very soon", however 4 months later and there's 
> absolutely no news about that... so depending on their definition of "soon", 
> maybe we have it here by 2013, and with no feedback whatsoever before that.  
>
> The funny thing: the website news where they mention the release of 3.0 it's 
> because the title of a book being published, called "OpenSceneGraph 3.0 
> Beginner's Guide"... a book ahead of it's time, I guess :)

No wonder they can't comply with their own schedule :) As you know, OSG
is a small project with only one leader. The intention of Robert Osfield
was to ship the next stable release with a shader compositing system,
since it is aimed to ease the coding in modern OpenGL contexts (GL 3, GL
ES 2, ...) where the fixed pipeline has been obsoleted or doesn't
exist. The problem is that, although some implementations were suggested
by other people, none of them seems to fit the bill of generality that
such a system would require. In addition, in the last months Robert was
swamped with client work, that although is OSG related, appears not to
be of shader compositing nature. I think that the size of the change and
the accumulated delay was the reason for replacing the next stable
release name from 2.8.4 to 3.0.

In the meantime, other OSG contributors do see an advantage in having
releases compatible with newer build systems, specially in Windows, even
they don't add any new functionality, because it's easier for their
customers to grab the prebuilt binaries during their OSG training
courses. Now in the list they are thinking about releasing a new 2.8
version, maybe 2.8.5, which will backport some specific plugin
improvements from the trunk. Again, this would fit that "de facto"
policy of "late branches".

The development continues at a steady rate in the trunk, with many bug
fixes and slight improvements. Every now and then, a new "developer
release" is stamped. IIRC, two days ago, 2.9.12 was released. The
problem is that those releases are not widely tested, and sometimes big
bugs are detected two or three weeks after the release. That's why I
prefer to have them in Debian experimental releases.

I agree with you in the fact that the versioning can confuse anyone not
following the mailing list, and that the homepage is not being correctly
synchronised either. The fact of the book having "3.0" in the title
demonstrates how soon that release was expected to be :) Obviuosly, the
book covers features up to the ones available in the trunk at the time
of the writing, so it can be a bit outdated when 3.0 comes out.

-- 
Regards,

Alberto



More information about the Pkg-osg-devel mailing list