Derek Wright wrote:
For example, merlinofchaos seems to treat each official release of views on his "stable" branches almost like a whole new release series on its own. He goes through the whole beta/rc process each time, gets lots of testing, etc. So, he still adds new features, and sometimes even alters the schema (as per his message to the other thread). views is probably the single most important contrib module, with literally 1000s of sites depending on it. Because Earl is so careful, and because everyone has an interesting in helping him test/debug new views releases, this system works pretty well, and allows him to not go completely insane supporting way too many different versions of the views codebase. That said, if he's adding new features to 5.x-1.x-dev on the way to the 5.x-1.7 release, and there's a security bug in 5.x-1.6 he has to fix, he's in something of a bind, since there's no good way to quickly get a 5.x-1.7 out to just fix the security problem without also introducing potentially instable code from the new features he already added. :( So, I can't recommend this as a Best Practice(tm), and it really only works for Earl since he's super-human. ;) Also, he's careful not to commit new features that are "too big" on his stable series, and certainly not fundamental re-factoring of the API, schema, etc.
True; I am very, very strict about actual API changes that will impact existing modules. I'm much less strict about new features, especially when many of them are simply missing features that are of minimal impact to existing installations. There's a lot of stuff that turns out to be really useful, and I'm not operating on the same scale that Drupal itself is, in terms of features. Though actually, the way it's been lately, I will likely have an almost 1 year gap before Views sees new features =)