Re: [boost] [1.36.0] Release schedule set

From: James Sharpe (james.sharpe_at_[hidden])
Date: 2008-05-24 20:42:04

2008/5/24 Frank Birbacher <bloodymir.crap_at_[hidden]>:
> Hi!
>
> James Sharpe schrieb:
>> Besides I don't think that subversion would move
>> away from using paths for branches since its at the very core of how
>> it has been designed (the model seems attractive at first but in
>> reality it becomes a pain as it allows users to do very silly things
>> to the repository)
>
> Attractive Model? Can Do Silly Things? That's the same as with C++,
> isn't it?

Indeed albeit one that most people are less familiar with the silly
things that can be done(and also that they only bite further in time)

>
> The flaw IMO is that the svn up does not follow renaming. But you would
> only want it if the root of your working copy moved. If only a subdir
> moved, i.e. current location was deleted, you don't want svn to switch
> your subdir to the new location.
>
> There are issues with svn. But the model is simple and works quite well.
> Just because the "svn up" command doesn't cope with renames, well, just
> always use "svn switch $MY_SVN_URL_at_HEAD ."
>
Point taken, but its far from ideal since it requires me to remember
the url or look it up when I need to update. Yes it is a simple model
that works for the most part, but currently makes things harder than
it needs to be when it comes to merging changes; just try a
distributed VCS and you'll see how easy merging becomes, and in fact
also how much easier branches are too for that matter.
Don't get me wrong subversion is a great tool, but I think that the
next generation is taking over; its reminiscent of the move of
projects from cvs to svn; a lot of projects said cvs works fine for us
until they made the move, at which point the benefits of svn became
clearer. I believe we're seeing a similar move with distributed
version control systems, which in general is an enabling tool for open
source; it enables easy forking, branching and contributions, and in
fact promotes higher quality patches and history due to history
rewriting and being able to commit offline(which for me is one of the
biggest advantages of using a DVCS over subversion; I can keep local
patches in my own repository until they're tested and proven ready for
integration upstream)

Take a look at Linus' presentation on git
http://www.youtube.com/watch?v=4XpnKHJAok8 for more information on how
git differs from CVS/SVN.

Anyway I feel this discussion is wandering OT, since we've lost focus
on the topic at hand: the release process; the fact is we can use DVCS
(be it git, bzr etc...) over the current subversion repository
(conversion to these tools can be considered at a later date once a
few developers have experience of using them for boost) and that these
tools help in easing merging of branches, which is IMO the key part of
easing the release process.

Obviously one of the biggest consideration when we start to talk about
more use of branches is that of testing; how do we distribute our
testing resources sufficiently over the branches? This is where I
think that branching from trunk as the next stable release as opposed
to release is an advantage. Current policy states that regression
tests on trunk must be stable before being merged to release, but
obviously where library interdependencies come into play this change
might not be quite so stable on the release branch, I think that
branching from trunk is a better policy and then reverting changesets
that cause regressions, at point of release, if they can't be fixed.
This is a similar model to what the kernel uses: have a merge window
in which some destabilization is allowed. The remainder of the release
time is then stablization of the release.

The way I would envisage this style of process working for boost is:
* stable feature additions/bug fixes occur to trunk at any point in
the release cycle
* on a given date(on day of release of first of previous release
series - there's no point in waiting to branch!) trunk is branched to
the next release branch (this date is made know well in advance so
developers know that towards this date they should be stablizing
regression tests on trunk ready for the branch)
  Release testing resources begin testing this branch (these release
testers should run at least once a day, but preferably on every
commit)
* this release branch is used for a series 1.x.y - 1.x.z, a release
manager is assigned to look after this branch of releases
* the first release 1.x.0 is released with a similar process from the
six weeks mark that Beman describes at
http://svn.boost.org/trac/boost/wiki/ReleaseSchedule although the
timescale can now be modified to lengthen the bug fix changes - there
should be NO new features(and in most cases no changes to the API -
this gives a longer period for documentation to be checked) added
though since this should be done on trunk before the release. After a
certain date (maybe 4 weeks before release) if a feature is still
causing large regressions at the discretion of the release manager
this change can be reverted.
* Once the release is done the testers for this release branch are
reduced to an on commit testing regime (they will also now be testing
for the next release branch that has just been created) and this
branch is now only committed to for regressions from the release state
of the regression tests and bug fixes filed against the last release
in trac. No other commits should be allowed on this branch. Then point
releases are made fortnightly while there are fixes to be released -
this branch is of lower priority with the testers ( but should
additional resources become available then more frequent tests can
occur)
* In this scheme development of potentially disruptive or breaking
changes should be initially developed on a branch (using distributed
tools this could in fact be a potentially non-publically visible
branch - which can then be rebased as a series of commits against
trunk). This can then be merged into trunk just after a release branch
has been created in order to maximise the time for stabilizing this
change against the regression tests.

Comments on this as a proposed release structure?