Robert
Something I have been wondering about is the differentiation between osg
versions. Perhaps this has already been covered, but I notice from the
mail that some users have problems with the (wrongly) mixed use of
versions - but that is during development.
As osg is becoming more widely used for applications, it is more than
likely that an end user of more than one application will have different
osg versions for each of the applications.
I know some dlls attach the version number to the dll. e.g mfc71. This
avoids the worst of the possible problems and they can usually be
updated if the API is not affected.
What is the situation with osg? Do we have to ensure that the
appropriate osg dlls are in the same folder as the application because
that is usually the first place that is examined for the dll.
Perhaps dll problems are just a function of Windows - I do not have
experience of other systems.
Regards
Alan Harris
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
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
