...
For what concerns the format of tags recognized by CMT, it appears that it is a lot more liberal that what one generally thinks. Actually, CMT only focus on the numbers in the tag names. It is up to the collaboration to choose one format or the other. The only advice given by CMT authors is to avoid dots, if the CMT is used together with CVS, because CVS will not like dots in the tag names.
| Wiki Markup |
|---|
The format which is generally used in the CMT documentation can be expressed thanks to this perl expression : v\[0-9\]\+(r\[0\-9\]\+(p\[0\-9\]\+)?)?. Yet,For onlyease the numbers are really meaningfull to CMT, andof reading, we dowill notcall know to what extent the tag v3p1 could be considered equivalent to v3r1, or even to MyPackage-v3p1. I suspect it is not fully consistent, as seen in some bugs, and it must be investigated.it v*r*p* below, but one must note that v*r* can be used, but not v*p*. In some situations, CMT only focus on numbers in the tag name, so v3p1 could be considered equivalent to v3r1... |
Also, CMT is meant to be used together with a version management tool, such as
CVS or subversion, but it tries not to depend on specific aspects of any of these
toolsAlso, CMT tries to be independant of the versions management tool (CVS, SVN) and its concepts. In particular, CMT is not aware of CVS branches. Badly enough, CMT developers
uses the term "branches" for the subdirectories of a package.
CMT only cares for tags, and it get those tags for a CVS package thanks to the command "cmt cvstags". The way the tags are ordered is unclear and linked to the implementation of the cmtcvs pluggin which is installed in the CVS repository. My current understanding is the following :
...
- If the first tag returned by "cmt cvstags" must be filtered-out, then the
following tags are ordered chronologically, which means the branch ones
could come first if they have been made lately.
This make me think that it is dangerous to rely on the ordering of
the output of "cmt cvstags", and dangerous to modify the cmtcvs pluggin without
consequences on the general behavior of cvs. Perhaps we could try to affect only the
selection of the first tag, but this would need to be done again each
time a new version of the pluggin is delivered by CMT authors.
Release Manager LATEST
| Wiki Markup |
|---|
The Release Manager is filtering out all the tags which do not match v\[0-9\]\+(r\[0\-9\]\+(p\[0\-9\]\+)?)?. This is a way not to take into account the tags which are applied on CVS branches, provided the developers do not use this format of tags on the branches ! |
LATEST is only applied to GlastRelease packages, not to EngineeringModelsaid to be only for GlastRelease, and not for other check out packages. Actually,
I feel it as a place where to check that the head of each package stay up-to-date with
the head of its providers and clients. I would not say it is GlastRelease oriented or Engineering oriented. It is rather "cvs head" oriented, so to remember to each package owner he must keep in touch with other packages evolutions.
Since LATEST is meant to take the latest trunk tag of each package, a way to get those
tags is to ask developers to use v*r*p* only on the CVS trunk, and just select the
last one.
Release Manager HEAD
The tags which are used in a HEAD build are explicitly defined one by one, under the controll of Navid. There are HEAD version for every check out package : BeamtestRelease, EngineeringModel, GlastRelease and ScienceTools. By default, the selected tags should follow
the same rules as LATEST applies for the name of tags, except for the preparation of patch versions.
For example if we prepare a v9r0p1 for GlastRelease, and some packages have received
modifications we do not want to incorporate
Branch Tags and Tags on Branchs
for LATEST, but there are situation where one could need a branch :
- We are preparing a patch for a given version, for example GlastRelease v9r0,
but one of the package to be patched has always been strongly modified for some
future big version. Then we need to start a branch from the tag used for v9r0.
- Two checkout packages are relying on two different version of a given
low level package. Typical case : EngineeringModel requires a different
Event from GlastRelease. Then we again need a branch for Event.
What we are developing on those branches should not affecty LATEST, yet we
should establish a policy so to easily recognize the branches and tags which
are meant for next HEAD and official versions. For a given <package>, whose
last GlastRelease HEAD tag was v<i>r<j>p<k>, the current policy is :
- The branch should start from <package> v<i>r<j>p<k>,
and the branch tag should be called GR-v<i>r<j>p<k>.
- The future tags on the branch should be called v<i>r<j>p<k>gr0, v<i>r<j>p<k>gr1,
and so on.
In some place, a confusion is made I suspect there is a confusion, at least in my head, between the tags which are defining a branch, and the tags which are applied to some revision which is on a branch. I will try Try to always distinguish between the betweenthe former, which I will would call "branch tags", and the latter, which I will would call
"tags on branches".
In some place related to the Release Manager, it is said that the tags v*r*p* should not be used on branches, and that the Release Manager is filtering out whatever tag is not v*r*p*, so to avoid branch tags. It is unclear if we mean branch tags, or tags on branches, or both.
The Art of Use in Requirements
Where to use specific tags ?
Where to use generic ones such as v12r* ?
To be writtenOn the other hand, sometimes we prepare a GlastRelease v*r*p*, with the p* which means one of the constituent package is branched. And the release manager HEAD is expected to be a preparation for this new GlastRelease v*r*p*, and the release manager LATEST is expected to be a preparation for HEAD... so it is expected that some tags on branches will be used in LATEST, then in HEAD, then for GlastRelease v*r*p*.
Places where there is information about tags
...