On Tue, 2008-08-05 at 13:20 -0400, Will Coleda wrote: > On Tue, Aug 5, 2008 at 1:10 PM, chromatic <[EMAIL PROTECTED]> wrote: > > Gah, no maintenance releases please! See "Mommy, why did it take over five > > years to release a new stable version of Perl 5 with a bugfix I made in > > 2002?" > > Perhaps I used an official term when I didn't mean to here. > > Let's simplify: I can easily see us needing at least "dev" and > "production" branches (one of which can be trunk), which is one more > than we have now.
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. 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. 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. Several SCMs make it easier to cherry-pick changes from the branch, merge them back to trunk, and keep the diff in even a long-lived feature development branch as small as possible. git for example (combined with Stacked GIT or a similar tool) has decent support for altering existing commits in a branch to make them easier to merge piecemeal. I don't have enough SVK fu to know how well this development model is supported there. -'f
