[Dev] Alpha releases [Was : Phases and 0.7 milestone schedule]
jeffrey at osafoundation.org
Mon Feb 13 19:01:56 PST 2006
> I agree with all of this on a general level: we need to find a process
> to stabilize the release in the end of cycle.
> There are 2 ways of doing this:
> - policing the commits: that's basically Alec's proposal here above
> - branching: used in other Open Source projects (see Fogel's)
> I think we can go away with policing right now because we do not have a
> lot of outside contributors with commit privileges. We can therefore
> hold on patches during the end of cycle phase. Note that this process
> may stall some developers (working on feature straddling 2 releases for
> instance). Those can always create their own working branch (as Andi did
> at the end of 0.6 for instance) but that's a burden on them to merge
> everything back once the release is declared.
> Branching is less constraining from a development standpoint but there's
> the added burden of committing to 2 branches for a substantial amount of
> time, something we may want to avoid right now. Eventually (when we have
> a big enough community of committers), branching might be the only way
> to go though.
This relates, I think, to how atomic our commits are. One of the points
in the Fogel book seemed to be that it's important to make atomic
commits, splitting changes into the smallest logical part. I think if
we did that more consistently, the pain of committing to two branches
would be somewhat lessened.
I'm not sure I actually *like* asking people to consistently split their
commits up, though. It's very convenient to make a variety of changes
in one commit, at our current size this doesn't feel like a major
problem, and it's certainly a widespread practice. But perhaps it's
worth thinking about.
More information about the Dev