7:54 p.m.
Hi,
On 03/11/2013 05:15 PM, Ayal Baron wrote:
> I was thinking we could lower the cost of making a point release
to
> the point where we could have a release every month... like this:
I'm not sure I understand what below reduces cost of making the point release.
Just this:
> The only release that should take longer than a couple of hours
to
> put
> out is 3.3.0 - the other releases are a tag in the source code, and a
> pointer to specific nightly builds.
> May: 3.3.alpha1 released - in-progress work, contains some early
> features, aimed for testing to identify features that need additional
> work early. Release branch is made now.
From this point there are no more point releases to 3.2 then, correct?
It's always possible, but that's the general idea. You're 2 months from
the stable release, no new features go in the release branch, and you
need to concentrate on getting the next release out.
> June: 3.3.alpha2 released - corresponds to feature freeze. At
this
> stage, incomplete features should no longer be committed. Work can
> start
> on testing, integration testing, bug day
No longer committed to the 3.3.alpha2 branch you mean? since as you've stated above,
there shouldn't be a 'quiet' period in master as it deters contributors.
Let me explain the branching strategy below - it's pretty standard in
several open source projects, but maybe people aren't familiar with it.
> The only release that should take longer than a couple of hours
to
> put
> out is 3.3.0 - the other releases are a tag in the source code, and a
> pointer to specific nightly builds.
I don't see how that is possible. 3.2.1 in this way will contain new features and
code which is not fully tested yet (negative flows etc) so you may come out with a release
which is less stable than the base version (3.2).
OK - here's a quick ASCII Art branching strategy for a release cycle.
If everything is committed to trunk, your branch tree looks like this:
Trunk
|
| Feature 1
+---+
| | Feature 2
+---+---------+
| | |
| | |
+---+ Merge |
| |
+-------------+ Merge
|
|
Now, you want to make a new major release. At feature freeze (when all
features to be included are complete), you create a release branch.
Trunk
|
| 3.3 release branch
+---------------------------+ <- Feature freeze/branch creation
| |
| |
| |
| Feature |
+---+ |
| | Merge fix |
+---+---------------------> |
| | |
| | |
+---+ Merge |
| X <- 3.3.beta1 release
| |
| Merge fix |
+-------------------------> |
| |
Features and bug fixes continue to get done on the trunk, and those
which are for the 3.3 release get merged into the 3.3 release branch.
3.3 releases are made off the 3.3 release branch.
The 3.3.0, 3.3.1 and 3.3.2 releases are all tagged on the 3.3 release
branch.
Development continues on the trunk throughout this time. At some point,
the difficult part of this (committing fixes to the trunk and then
merging them to the 2.3 branch) slows down or stops, and everyone is
once again concentrating on the trunk, until such time as the 3.4 or 4.0
(or whatever you decide to call it) release branch is created.
Once we "abandon" the 3.3 branch, there is no point in continuing to
make point releases there. It serves the project better to have a period
where everyone is concentrating on implementing new features and
integrating them into the trunk, rather than having attention split
between maintenance and new development indefinitely. In general, 6
weeks after a release is enough time to identify and take xcare of the
biggest issues in the release.
Does that help explain what I have in mind better?
Thanks,
Dave.
--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13