Option 2 is better. 2016-06-20 21:16 GMT+07:00 Jan Ciger <[email protected]>:
> > > On Mon, Jun 20, 2016 at 2:13 PM, Alberto Luaces <[email protected]> wrote: > >> Robert Osfield writes: >> >> > Thoughts? >> >> In my opinion, a new repo implies extra maintenance duties (even they >> are likely low), but cannot guarantee that it is synced or working with >> the latest OSG version, so it has a little added value. >> > > > Wasn't the entire point of having the dead code in a separate repo that it > won't need to be maintained? If someone still wants to use it, it will be > available, just not necessarily compiling with the current OSG and they > would have to put some elbow grease in it to make it work again. > > Personally I don't have an issue with it. There is little point in > spending resources on things that are not being used but still have to be > maintained only because someone could find the code potentially useful in > the future. > > I would adopt a 2 step process for it, though - mark the bits to be > removed as deprecated in version N first, including warning messages being > printed, etc. and only remove it to a separate "attic" repo in release N+x, > where x is to be defined. Not everyone that uses OSG follows the list or > updates to the current version as soon as it is released, so that should > give them an ample warning. > > J. > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
