"Nicola Musatti" <Nicola.Musatti@gmail.com> wrote in message news:loom.20060512T133243-385@post.gmane.org...
Pedro Lamarão <pedro.lamarao <at> intersix.com.br> writes: [...]
Beman Dawes escreveu:
"Formal releases occur on a regular schedule. The formal release procedure is simply to package up the last tagged revision of stable, publish release candidates, and decide if there are any issues serious enough to wait for the next stable tag point."
If this process would contemplate a bugfix branches associated with stable tags, and if some backporting fixes effort were made, the people complaining about API stability would be happier.
I agree. In my opinion a new branch should be created on STABLE for each formal release. Its main purpose would be to provide an escape should anything go wrong with the formal release, but it would also be available for smaller scale bugfixing and backporting, subject to availability of necessary resources; I'm aware that control should be exercised over what is committed on the formal release branches, especially since these do not have an associated "unstable" branch. People wishing to contribute to a bugfix branch should ensure that a reasonable amount of regression testing is performed before the branch is given a new "stable" tag.
With SVN, the distinction between a branch and a tag is blurred. They are both really just (virtual) copies at a given point in time. It is up to us exactly how we want to organize the releases we do. If I understand you correctly, you are pointing out that sometimes we may want an explicit bugfix branch of STABLE rather than just moving on to the next week's STABLE tag point. We can certainly do that if useful. At this point, I'm not sure we want to try to micro-manage those future decisions. Rather, we can just make adjustments as we gain experience.
Note that this would require a change in the release numbering scheme; a couple of alternatives could be to add a fourth number for the weekly tags or to just use the date in the YYYYMMDD format.
I thought of that, but decided to recommend keeping the initial scheme simple and a continuation of the current, familiar numbering scheme. Thanks, --Beman