First of all: I'm OK about the change of the deprecation policy. Removing the autotools support is OK with me too. The brlcad.dll build is implemented in CMake only.
But: There could be other users/systems which run into trouble because of CMake and the CMake version required. E.g. your own server ftp.brlcad.org has CMake 2.8.2 installed but BRL-CAD requires version 2.8.4. There may be other more important systems with a similar problem. Until now using autotools is a workaround. Daniel 2012/5/2 Christopher Sean Morrison <[email protected]>: > > Hi All, > > Repeating a dialog I shared on the IRC channel, I think it would be good to > discuss and revisit our deprecation policy some since it's come up a few > times over the past year. For those that aren't aware, we have a deprecation > policy documented in doc/deprecation.txt [1] and it's been in practiced use > for several years now. > > I think it's important as a community that we agree to a deprecation policy > and stick to it, otherwise our users cannot rely on us and that hinders > adoption and growth. We don't want to get the same bad rap as the Firefox > folks. We don't have their karma to burn. ;) > > The intent of the policy as it was originally written was that our community > (users and developers) are guaranteed at least two full minor releases over a > 3-6 month timeframe to adjust to changes we make. The first minor release > introduces the change to our community. The second minor release gives them > time to schedule a review and accommodate the change. Then the feature is > finally removed sometime during or after the third minor release. > > Strictly interpreted, the original wording implied that three minors needed > to include the notice, so if we deprecated in 7.21, then 7.28 was the soonest > it could be removed. If we deprecated in 7.22.2, the same 7.28 release was > the soonest. The idea was that a user/dev won't necessarily update during a > patch revision, so the first they read about the deprecation might be the > next minor. That meant four minor releases from deprecation to removal. > Given the pains this has caused on rare occasion (jove, autotools), what are > thoughts on tightening this to three minor releases? > > I've just finished clarifying the language and provided a specific example > for extra measure. It reduces the window to three releases (two including > the announcement, removed on or after the third minor). So if you deprecate > in 7.21 or 7.22, then you can remove in 7.26+. I think this tightens up our > policy about as tight as it can get while still giving our community > guarantees. It lets us change features we've published pretty quickly (3-6 > months), but not recklessly. > > I know we can turn around updates that quickly with most of our internal > codes, so the concern is primary with external code developers. For that, > I'm looking to you guys (Daniel, Tom, ..) that integrate our libs with other > codes and have to deal with API deprecation on a regular basis.. > > Objections or concerns welcome. Still provides a minimum of three months, > but doesn't accommodate folks that only sporadically pay attention to our > releases. I don't think this change will affect most people (ourselves > included) 99% of the time, but it should make our development just a little > more fluid on those rare occasions (removal of jove, autotools) where there's > often a maintenance burden. > > Cheers! > Sean > > [1] > http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/deprecation.txt > > > On May 1, 2012, at 10:06 PM, [email protected] wrote: > >> Revision: 50398 >> http://brlcad.svn.sourceforge.net/brlcad/?rev=50398&view=rev >> Author: brlcad >> Date: 2012-05-02 02:05:57 +0000 (Wed, 02 May 2012) >> Log Message: >> ----------- >> revert r50386,50391-50393 as removal of prior build system is very >> premature. it was just deprecated in 7.20.0 and is supposed to exist >> deprecated across three minor releases. implies 7.24.0 would be the soonest >> (or 7.26.0 if interpreted strictly), and we're not even to 7.22.0 yet. >> >> Revision Links: >> -------------- >> http://brlcad.svn.sourceforge.net/brlcad/?rev=50386&view=rev > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > BRL-CAD Developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/brlcad-devel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
