On Tuesday 05 August 2008 12:35:50 Geoffrey Broadwell wrote: > We will definitely need multiple long-lived branches. Just to make > explicit the reasoning: data loss, security, or otherwise critical > bugfixes that should be backported to one or more already released > versions and re-released immediately. That's a lot harder if you don't > have release branches. Of course, you can branch lazily, since releases > are tagged. But we have to assume that there *will* be multiple > long-lived branches that won't merge and go away.
That's horrible. I doubt you give morphine to a five year old who falls and scrapes his knee. This is the equivalent in releasing software. I can see patching the previous release in case of a critical bugfix, but if we get in the habit of encouraging users to expect updates of anything older than the previous stable release for free, we've doomed the project. Point releases every month. Major releases every three months. Complete and utter refusal to support users who expect that they can install Parrot 1.0 and get free support from the mailing list or IRC for the next eight to ten years. If we don't set those expectations now, we might avoid the problem of these leeches in the future. (Again, see Perl 5 for an example of why maintaining multiple stable branches doesn't work, why encouraging people not to upgrade doesn't work, why release candidates don't work, and why feature-based releases don't work.) > However, I'm against the practice of branching before release to > "stabilize" an assumed-crazy trunk. I prefer the (general) way we do > things now: releases are made from the trunk code, which is kept as > high-quality as possible; small changes are made directly to trunk; > large changes are made in a branch and merged to trunk when ready. Agree. > The details may be ripe for improvement, however. There seems to be an > implicit assumption from at least some of us that a "merge back to > trunk" should be (or even 'needs' to be) an all or nothing affair. Traditionally, it has been. If mergebacks are small and frequent, I can live with long-lived branches. The problem isn't that branches live too long. The problem is that features are too big and take too long to develop. Small, working, isolated steps are always better than big thuds. Branches only seem to protect us from those big thuds by keeping trunk stable. (If you can't keep your branch stable... well, there's another problem obvious to anyone who watched the concurrency branch.) -- c
