Re: [eclipse-dev] consistent CVS tags for builds?

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Consistency is good, and the proposed
convention almost makes sense. The only difference I would suggest is to
put the branch tag at the start of the qualifer rather than the end. The
advantage of doing this is that it causes builds on the same branch to
be grouped together in a lexicographical sort. The is useful when doing
things like "Compare/Replace With > Version", where lists
of CVS tags are shown in sorted order. Instead of having the builds from
a given branch mixed in with builds on other branches depending on the
day they occurred, you get them all grouped together. You can easily find
all the versions that occurred on branch X.  Essentially, I'm suggesting
what we wrote in the versioning guidelines: http://wiki.eclipse.org/Version_Numbering#When_to_change_the_qualifier_segment

Note that the problem of non-increasing
qualifiers no longer affect us when using p2. p2 lets you deliver a new
build that contains older versions of plug-ins if you so desire. Still,
a consistent convention that sorts nicely is useful because these tags
appear in sorted order in various places in the CVS UI.

John.v20080416-2036

Boris Bokowski/Ottawa/IBM@IBMCA
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

04/16/2008 04:08 PM

Please respond to
"General development mailing list of the Eclipse project."        <eclipse-dev@xxxxxxxxxxx>

To	eclipse-dev@xxxxxxxxxxx
cc
Subject	[eclipse-dev] consistent CVS tags for builds?

The component teams seem to have different conventions for CVS tag names
when doing build submissions.  I believe that consistency is a good
thing
unless there are good reasons for tag name creativity (are there any?).
In
the past, we even had to re-spin builds because inconsistent tag names
lead
to non-increasing bundle version numbers. (To be fair, this only happened
if one component in itself was inconsistent though.)

CVS tag names appear in bundle version numbers, in the bundle jar file
name
or directory name, and in the revision history for one specific file. They
should increase lexicographically over time as long as the major, minor,
and service segment of the bundle version number does not change, i.e.
within one development stream.

I would like to be able to derive the id of the build in which it first
appeared when looking at a revision of a file in the history view, or when
looking at a particular bundle somewhere on disk.

Kim Horne has volunteered to update the releng tools if we could agree
on
the following form for tags (sorry for being formal here):

"v<date>-<time><branch_opt>"

where
  date := the current date in yyyyMMdd format
  time := the current time in HHmm format
  branch_opt := "" if org.eclipse.releng is from HEAD,
                    
         "_<branch>" otherwise.
  branch := a compressed form of the branch from which org.eclipse.releng
is checked out.

The "compressed form" could be the first letter of the branch
name followed
by any numbers in the branch name. The reason for compressing the branch
name is that tag names appear in file names and directory names, and using
the full branch name would lead to overly long names that could cause
problems on certain file systems.

For example, a regular contribution for this week's integration build would
use a tag like "v20080414-1526", and a build submission for a
maintenance
build would use a tag like "v20080901-1130_R34". Looking at the
first
example tag, we can tell that it was made from HEAD for a regular
integration build some time after April 14, 2008.  The second tag
looks
like it would go into a maintenance build for the 3.4 maintenance stream.

Questions? Comments?

Boris

P.S. I know that this has been discussed in the past. I don't have much
hope that we can get everyone to agree on this, but I would consider it
an
improvement if *most* teams would use a consistent naming scheme.

_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev