Embed your release number into a tag.  For major releases, you can make a tag
like "rel-2-3" for Release 2.3 of the product.  For minor releases (perhaps only
used internally in the company in between major, "public" releases), you can use
a tag based on the date/time.  We typically make tags that look like:

     ajp-20000723

where ajp is the programmer's initials (A. Java Programmer), 20000723 is the
encoded date (July 23, 2000).  We often add a text suffix describing the
significance of the tag for ease of understanding:

     ajp-20000723-fixedInputQueue

and, if necessary, you can append the hour/minute if you have more than one in a
day:

     ajp-20000723-1423-fixedInputQueue

for a tag create at 14:23.  We document these tags in a file named cvsTags.txt
which is kept in the top-level directory of the module (or directory sub-tree)
affected by the tag, so the list of tags and their explanation is saved in CVS
right along with the code the tag applies to.

Good luck,
Alan Thompson











"Robert S. Sfeir" <[EMAIL PROTECTED]> on 08/09/2000 01:49:36 PM
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      Donald Sharp <[EMAIL PROTECTED]>, TC                 
          <[EMAIL PROTECTED]>                                  
                                                              
 cc:      Donald Sharp <[EMAIL PROTECTED]>,                    
          [EMAIL PROTECTED](bcc: Alan Thompson/Orincon)        
                                                              
                                                              
                                                              
 Subject: Re: Version numbers                                 
                                                              







Ok I didn't explain myself correctly.  Yes I don't care about the internal
number, and yes I would love to see a way for me to maintain my own
versions so I know exactly what's on the web box and what I have in
CVS.  So if I can have my own versioning increased based on what I do when
I check in, that would be great.  Is there a way to do this that I'm not
seeing?


Thanks.

R
At 03:30 PM 8/9/2000 -0400, Donald Sharp wrote:
>Ah but there is a big difference here between checking that
>a latest revision # is on a web box, and saying when I commit
>I want the revision # to look a certain way.
>
>What I probably should have said was:
>
>"Don't attempt to fit your projects version numbering scheme
>into cvs's version numbers.  Use tags( labels ) and branches
>to enforce this"
>
>donald
>On Wed, Aug 09, 2000 at 12:09:45PM -0700, TC wrote:
> > snip
> > >Don't look at the version numbers.  The cvs manual explicitly states
> > >that the numbers are control numbers internal to cvs,  and if
> > >you are looking at them you probably are trying to do something wrong
> > >with cvs.  Use labels and branches to provide what you are looking for.
> > >
> > >donald
> > I am not sure I agree with this...
> > In a dev Env a group of developers access a common web dev box for example
> > we run some portion of the web app, we just want to know that our last
> > commited code is on the dev box we can verify this by just checking
> > the $Id stamp. We are not at the point we want to tag a release we are just
> > deving
> > but we all want to see each others current work & be able to verify
> > this.....
> >
> >
> >


--
Robert S. Sfeir
"If We Quit Voting, Will They All Go Away?"




Reply via email to