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
