Hi all,
after our mini-fiasco with 3.1.4, and the delays of 3.2 in general, I'd
like to propose a few changes to our development release processes. John
made some suggestions here, which I'm formulating in this proposal.
Please discuss. And yes, we will update the release process on the Wiki
once we agree.
Cheers,
-- Leif
1. We formalize a strong development plan for 3.4, and we try to stick
to it. We tried this, very loosely with 3.0 and 3.2, and we failed
miserable. For v3.4, to meet a ~6 month release cycle, we have to
reduce the number of feature additions to something reasonable.
2. During the development release phase, 2 weeks prior to making a
release candidate, no feature additions are allowed. Period! Bug
fixes are obviously still allowed. (See the 3.3.x branch suggestion
below for how to deal with this).
3. In order to keep the momentums going, I'm suggesting three additions
to our git processes:
1. I've created a 3.3.x branch in git. This is the branch that gets
feature frozen 2 weeks prior to someone deciding to start a
release process. Anyone can merge master to this branch as
necessary, up until the 2 week release process starts. From then
on, we cherry-pick from master until the release is cut.
2. We create feature branches for very large additions. For
example, the DNS rewrite would be a branch, and the NUMA support
would be a branch. Adding support for raw devices in FreeBSD
would almost certainly not be a branch.
3. Reiterating on our existing process, the master branch on git is
still "commit then review". It is always open, it's always OK to
add features to it. To make things very obvious, lets be
religious about adding Jira tickets to all non-trivial commits,
and annotate the commits (and jira tickets) accordingly.
