On 9/14/2011 2:58 PM, Michael Parker wrote:
> So I guess I'm back to my last suggestion:
> September: Release from trunk, version 3.4.0, svn branched to 3.4.0 (not 3.4)
> January: Release from trunk, version 3.4.1, svn branched to 3.4.1
I'm -1 for this branching/release strategy.
I'm -1 as well for that strategy. Darxus, you have a false assumption
that 3.4.1 is a different branch than 3.4.0. It is not. 3.4.0, 3.4.1,
3.4.2, etc. collectively are all the same branch.
A good reason we branch instead of using trunk is that branches require
RTC while trunk does not to give some leniency to pursue some avenues
others might not enjoy. Lately, those changes haven't been very
controversial or broken anything horribly.
But, while I test with trunk, it's really the least ideal for a
production system.
The problem is that branches and trunk get out of sync require up and
back porting but that's just programming as normal on a project that is
co-maintaining multiple versions.
Our chair is not comfortable releasing from trunk and I don't feel
strongly enough about the issue to argue it.
So I think we have consensus from PMC members but just to be clear,
here's my first pass at a high-level to-do list which I vote +1. Please
note, this is likely a PMC only vote so I'm cc'ing the PMC list as well.
- 3.4.0 will be the next release
- 3.3.x development is ceased barring a major bug and we won't backport
changes currently in trunk to 3.3
- Add 3.4 SVN branch and 3.4.0 as a version for Bugzilla
- Add 3.4.1 as a version for Target Milestone
- Trunk switches to R-T-C as of today, 9/14 in preparation for the release
- Create a 3.4 branch in SVN based on trunk ASAP (I think there are
technical hurdles that make waiting until after the release difficult)
- Go through the 715 open bugs and identify the goals to finalize for
3.4.0 release
- Move all open bugs tagged for 3.3.x to 3.4.0 or 3.4.1 later based on goals
- Any patches to remove from 3.4.0? I know we have a bug or two with
rules that are disabled/removed to resolve.
- Open/edit bugs for 3.4.0 that have been discussed but not formalized
such as the sa-update and ipv6 hurdles
- Add a jenkins/hudson build for the 3.4.x branch
- Add DNS entries and make sure rule updates are ready for 3.4.x branch
- Goal is to prepare an rc1 for 3.4.0 on or about 9/30 through normal
procedures, voting, etc. moving toward an eventual release shortly
thereafter
- Post-release, trunk and 3.4 branch will be kept in sync perfectly and
all programmers will write code with zero bugs ;-)
Anything I missed?
regards,
KAM