On 6/8/12 5:16 PM, Nick Kew wrote:
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.
-0. Not a strong objection, but why the need for a 'strong plan'
an a six month cycle?
When we first went to Apache, we agreed on 6 months release cycles for
major releases. We can certainly revisit that if we don't want to do
that. The idea was to avoid year long release cycles, and 6 months
seemed reasonable. We have not yet achieved this, in fact, we're on
almost exactly 1 year cycles between major releases. :)
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).
I guess the solution here is to fork a release branch two weeks ahead
of rolling its release. Then only bugfixes are allowed in the branch,
while trunk rolls on as normal.
Right, that is the 3.3.x branch and cherry-pick from master. I wouldn't
personally branch every time, I'm not sure I see value in that (these
releases are linear). But if we want to create a new branch off trunk
every time (instead of just keeping 3.3.x merged as necessary), I'm not
opposed to that either. (fwiw, git is a much better tool suitable for
dealing with merges, compared to e.g. svn). We would still of course
create release tags for every release, that doesn't change.
As a response to John, I'm not opposed to feature freezing trunk for 2
weeks either. In fact, we had that as a proposal at some point, but some
people objected.
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.
Seems OK, except insofar as it begs the question of whether we want to
push everyone into creating jira issues even where they may seem pointless.
Sounds like you're basically saying jira should be a public record of
every non-trivial commit. I can live with that, but would just like to
confirm whether that's what you mean?
I think having to add a Jira ticket to say update the STATUS file with
something benign, or some of the other non code related changes is a bit
of a stretch. But, we can certainly make that a requirement too, if
that's the consensus here. I guess what I'm saying is for everyone to
use their best judgement. I do know that there have been a few commits
that most certainly should have had a Jira ticket associated with them,
and they did not.
Cheers,
-- Leif
