On Wed, Oct 20, 2010 at 11:56 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: IMO, the best release approach is to set a timeline for branching and then release the branch when it's done. This is basically how the Linux kernel works, for example, and how MediaWiki historically worked up to about 1.15. We'd branch every three months, then give it a while to stabilize before making an RC, then make however many RCs were necessary to stabilize. This gives pretty predictable release schedules in practice (until releases fell by the wayside for us after 1.15 or so), but not anything that we're forced to commit to. (Actually, Linux differs a lot, because the official repository has a brief merge window followed by a multi-month code freeze, and actual development occurs in dozens of different trees managed by different people on their own schedules. But as far as the release schedule goes, it's "branch on a consistent timeframe and then release when it's ready", with initial branching time-based but release entirely unconstrained. So in that respect it's similar to how we used to do things.) I don't think it's a good idea to insist on an exact release date, as Ubuntu does, or even to set an exact release date at all. That could force us to release with significant regressions if they come up at the last minute. On the other hand, I don't see any real benefits. Does anyone care exactly when MediaWiki is released? If so, why can't they just use RCs? The RC tarball is just as easy to unpack as the release tarball. I also don't think it makes any sense for us to do feature-based releases. The way that would work is to decide on what features you want in the release, then allocate resources to get those features done in time. But Wikimedia currently doesn't use the releases, it deploys new features continually. So resources will naturally not be targeted at the release date, they'll be targeted for deployment whenever they're done. Wikimedia has no big reason to pay people to rush to complete something in time for a release that it isn't going to use anyway. Furthermore, even if Wikimedia did use releases -- IIRC, you thought that was a reasonable plan when this came up before -- I still think feature-based releases are a bad idea. It encourages you to either delay releases excessively or ship half-baked features. If you instead say that you'll ship whatever is mature at the time of release, with no commitment to what makes it in, it encourages more focus on correctness and quality. Feature-based releases really only belong in the proprietary software world, where the vendor needs a feature list to encourage people to pay for the new version. IMO, no. I think it's best to just ship whatever's done when the release branch is made. Processes like Ubuntu or Mozilla have only make sense when the organization paying for development is primarily interested in the actual release, not when the organization is primarily interested in its own use of the product. In the latter case, it makes much more sense to do incremental development and deployment and do releases mostly as an afterthought. Wikimedia is in an unusual position here, really. Very few sites that pay for in-house code development for their own use then make real open-source releases of it. Either they keep it closed or just throw source over the wall occasionally, or they're interested mostly in getting third parties to use it. I'm not personally familiar with other open-source projects in a similar position to us, although they exist (like StatusNet?). We have to be careful with analogies to software development that's dissimilar in purpose to ours. IMO, it's essential that Wikimedia get back to incrementally deploying trunk instead of a separate branch. Wikipedia is a great place to test new features, and we're in a uniquely good position to do so, since we wrote the code and can very quickly fix any reported bugs. Wikipedia users are also much more aware of MediaWiki development and much more likely to know who to report bugs to. I think any site that's in a position to use its own software (even if it's closed-source) should deploy it first internally, and if I'm not mistaken, this is actually a very common practice. Beyond that, this development model also gives volunteers immediate reward for their efforts, in that they can see their new code live within a few days. When a Wikipedia user reports a bug, it's very satisfying to be able to say "Fixed in rXXXXX, you should see the fix within a week". It's just not the same if the fix won't be deployed for months.