Hi Alan, In the past the way to manage the different version was to keep the libs all local to your application.
For 2.0 we can potentially use CMake's support for versioning filenames, something that kinda complicates this is the GNU convention of using ABI numbers rather than version numbers. I am also thinking above naming the installed osgPlugins lib directory by the version number too. Robert. On 5/18/07, Alan Harris <[EMAIL PROTECTED]> wrote:
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 > [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/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
