On Mon, 1 Oct 2001, seb bacon wrote:
> Today, I said:
> > At the moment, if you don't know CVS, you pretty much can't use the
> > CMF, which is plain silly since it's all pretty stable.
>
> Tres has since pointed out that this is a common misconception, and
> that 1.1 does work with 2.4.1, which makes *me* plain silly :-S
>
> However, I'd still appreciate an explanation of the branching /
> release schedule for the CMF. In the repository, there are the
> following tags concerning 1.1:
>
> CMF-1_1-branch: 1.8.0.2
> CMF-1_1-release: 1.8
> CMF-1_1beta: 1.3
>
> Could someone walk me through the history and rationale of these tags?
The CMF has not (yet) adopted the rigor of Brian's release policy.
In particular, the 'CMF-1_1-branch' tag is a branch rooted at
'CMF-1_1-release', which was made *after* the 'CMF-1_1beta' tag.
In the future, I would expect to create tags / branches more in
line with Brian's model:
- During pre-beta development (beta represents "feature freeze"),
minor bugfixes are checked in on the head. Major bugfixes and
new features are developed in activity branches (e.g.,
'tseaver-ttwactions-branch'), and merged when ready (all tests
must pass on the merged sandbox before checking in the merge).
- At "beta", we create a new base tag and branch tag for the coming
release (e.g., 'CMF-1_2-base' and 'CMF-1_2-branch'). No new
features may be added on this branch. Releases (beta, final,
bugfix) will be made from this branch.
- "Beta" creates a feature freeze for that branch; other feature
development may continue in activity branches which will *not*
be merged to the release branch.
> AFAICT, there have been no bugfixes to any branch since July. In an
> ideal world, I am guessing these would have been applied to the
> 1_1-branch as well as the trunk.
Right -- we did backport a couple of patches, but quite a few haven't
made it. In part, that derives from our intent to have a more aggressive
release schedule for the CMF; I had originally planned to release
a 1.2 beta in mid-September, with a final ~ the end of the month.
> There are a few other branches from a while ago (listfoldercontents,
> extended_dcmi, alltypes) which appear to have been merged since. Is
> there a mechanism or policy for keeping up with merges or will they
> just get announced to this list?
Other branches are "activity" branches, made in order to isolate a
set of changes related to a given feature until the are ready for
merge. We would in fact prefer that all "major" work take place on
activity branches, in order to ensure that we leave no "guts on the
table" on the head of the tree.
> Apologies for checking on the minutiae, and perhaps repeating
> questions that may have been answered elsewhere, but I've not used CVS
> in projects with more than about 3 programmers sat next to each other,
> so I'm learning lots :-)
We're learning too; having "outsiders" looking over our shoulders
is going to make us do a better job of following our own policies,
I think.
Tres.
--
===============================================================
Tres Seaver tseaver@zope.com
Zope Corporation "Zope Dealers" http://www.zope.com
> Today, I said:
> > At the moment, if you don't know CVS, you pretty much can't use the
> > CMF, which is plain silly since it's all pretty stable.
>
> Tres has since pointed out that this is a common misconception, and
> that 1.1 does work with 2.4.1, which makes *me* plain silly :-S
>
> However, I'd still appreciate an explanation of the branching /
> release schedule for the CMF. In the repository, there are the
> following tags concerning 1.1:
>
> CMF-1_1-branch: 1.8.0.2
> CMF-1_1-release: 1.8
> CMF-1_1beta: 1.3
>
> Could someone walk me through the history and rationale of these tags?
The CMF has not (yet) adopted the rigor of Brian's release policy.
In particular, the 'CMF-1_1-branch' tag is a branch rooted at
'CMF-1_1-release', which was made *after* the 'CMF-1_1beta' tag.
In the future, I would expect to create tags / branches more in
line with Brian's model:
- During pre-beta development (beta represents "feature freeze"),
minor bugfixes are checked in on the head. Major bugfixes and
new features are developed in activity branches (e.g.,
'tseaver-ttwactions-branch'), and merged when ready (all tests
must pass on the merged sandbox before checking in the merge).
- At "beta", we create a new base tag and branch tag for the coming
release (e.g., 'CMF-1_2-base' and 'CMF-1_2-branch'). No new
features may be added on this branch. Releases (beta, final,
bugfix) will be made from this branch.
- "Beta" creates a feature freeze for that branch; other feature
development may continue in activity branches which will *not*
be merged to the release branch.
> AFAICT, there have been no bugfixes to any branch since July. In an
> ideal world, I am guessing these would have been applied to the
> 1_1-branch as well as the trunk.
Right -- we did backport a couple of patches, but quite a few haven't
made it. In part, that derives from our intent to have a more aggressive
release schedule for the CMF; I had originally planned to release
a 1.2 beta in mid-September, with a final ~ the end of the month.
> There are a few other branches from a while ago (listfoldercontents,
> extended_dcmi, alltypes) which appear to have been merged since. Is
> there a mechanism or policy for keeping up with merges or will they
> just get announced to this list?
Other branches are "activity" branches, made in order to isolate a
set of changes related to a given feature until the are ready for
merge. We would in fact prefer that all "major" work take place on
activity branches, in order to ensure that we leave no "guts on the
table" on the head of the tree.
> Apologies for checking on the minutiae, and perhaps repeating
> questions that may have been answered elsewhere, but I've not used CVS
> in projects with more than about 3 programmers sat next to each other,
> so I'm learning lots :-)
We're learning too; having "outsiders" looking over our shoulders
is going to make us do a better job of following our own policies,
I think.
Tres.
--
===============================================================
Tres Seaver tseaver@zope.com
Zope Corporation "Zope Dealers" http://www.zope.com