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

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I guess this convention will break in
the 3.6 release because v1000 comes before v999 in a lexicographical sort.
I don't see a big advantage to maintenance branches sorting consistently
with builds in the main HEAD branch.  Say v854 was the final build
for the 3.4 release.  Then you have v855, v856, etc for all the builds
in the 3.4.x maintenance branch. From looking at the qualifier numbers
v900 appears to be a newer and better build than v860, even though v860
is likely much more recent and has more fixes than v900. After the point
of the fork, there isn't any meaningful way to compare builds in the branch
to builds in HEAD - they may have the same changes, or completely different
changes.

Philippe P Mulet <philippe_mulet@xxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

04/17/2008 05:39 AM

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

To	"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
cc
Subject	Re: [eclipse-dev] consistent CVS tags for builds?

Still lexicographically, the maintenance versions should look posterioir
to its pre-release counterparts.

As a point of interests, JDT/Core uses a different convention, e.g. today
is v_854 (i.e. the 54th drop in the 8th release). When starting working
on 3.5, we will increment to v_900. Imagining that 3.4 is v_870, our subsequent
maintenance drops are: v_871_R33x, v_872_R33x... so they sort fine, and
group ok as well... When we need the date of the build, we refer to the
corresponding build notes. 

The new story should achieve something similar, which I do not see yet.
Also, JDT/Core would have a hard time with new proposed story, as versions
with new format would sort before versions with our present format. This
would be a no-go for us.

Daniel Megert <daniel_megert@xxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

04/17/2008 09:03 AM

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

To	"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
cc
Subject	Re: [eclipse-dev] consistent CVS tags for builds?

>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.

Interesting news John! How is that achieved? For us the versioning scheme
has to work also when patching the build with our exported plug-ins (i.e.
not a complete new build). The reason for Boris's approach (i.e. tag at
the
end) was the fear that we forget to increment the service number for a
maintenance build and when using "r..." for tagging it would
result in a
lower version than for the main release itself where "v..." was
used. If
this is indeed no longer a concern and p2 always takes the latest installed
plug-in in case of identical "major.minor.service" number then
I'd vote for
John's approach - otherwise +1 for Boris's suggestion.

Dani


                    
                     
                     
         
            John Arthorne      
                     
                    
            <John_Arthorne@ca    
                     
                  
            .ibm.com>      
                     
                     To
            Sent by:      
           "General development mailing
list   
            eclipse-dev-bounc    
    of the Eclipse project."        
   
            es@xxxxxxxxxxx    
       <eclipse-dev@xxxxxxxxxxx>    
      
                    
                     
                     
      cc 
                    
                     
                     
         
            17.04.2008 02:37    
                     
           Subject 
                    
                 Re: [eclipse-dev]
consistent CVS    
                    
                 tags for
builds?                  
 
            Please respond to    
                     
                  
                "General  
                     
                     
   
               development    
                     
                     
             mailing list of    
                     
                   
               the Eclipse    
                     
                     
                project."
                     
                     
    
            <eclipse-dev@ecli    
                     
                  
                pse.org>  
                     
                     
   
                    
                     
                     
         
                    
                     
                     
         





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          
                     
 
                    
                     
                     
      To 
                    
                     
                eclipse-dev@ec
04/16/2008 04:08 PM                
                     
 lipse.org      
                    
                     
                     
      cc 
                    
                     
                     
         
               Please respond to  
                     
         Subject 
   "General development mailing list of the      
         [eclipse-dev]  
               Eclipse project."
                     
    consistent CVS 
           <eclipse-dev@xxxxxxxxxxx>  
                    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
_______________________________________________
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


_______________________________________________
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



Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 542.737.118 €
SIREN/SIRET : 552 118 465 02430
_______________________________________________
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