commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John McNally <jmcna...@collab.net>
Subject Re: non-release (vendor/developer) tags
Date Tue, 08 Jul 2003 03:44:46 GMT
It is possible, unless disallowed by the cvs admin.  It can be used as a
way of managing a release as well as cleaning up a  mistake.  In some
environments it may be more difficult to freeze development on a branch
or the release is just not suppose to include everything on the branch. 
A release team may create a temporary tag, so that it is not confused
with an actual release, they then move the tag around during testing and
when ready, the official release tag is created and the temporary tag is
removed.  That might not be the best explanation, but anyway it is
possible and has uses whether or not such a uses would be considered
best practice I'm not sure.

john mcnally

On Mon, 2003-07-07 at 19:43, David Graham wrote:
> I don't see any problem either but I think a generic name is preferable. 
> Can you actually "untag" the code?  I thought once it was tagged it was
> there forever.
> 
> David
> 
> 
> --- "Craig R. McClanahan" <craigmcc@apache.org> wrote:
> > I don't see aany problem with non-release tags like this.
> > 
> > Craig
> > 
> > On Mon, 7 Jul 2003, John McNally wrote:
> > 
> > > Date: 07 Jul 2003 18:34:58 -0700
> > > From: John McNally <jmcnally@collab.net>
> > > Reply-To: Jakarta Commons Developers List
> > <commons-dev@jakarta.apache.org>
> > > To: commons-dev@jakarta.apache.org
> > > Subject: non-release (vendor/developer) tags
> > >
> > > Is there a policy in jakarta-commons on tagging the cvs repo?
> > > Here is my situation: I use dbcp in its current HEAD state.  It is
> > > stable for my usage.  However there is a critical bug and the desire
> > by
> > > developers to rewrite large portions of the code, essentially removing
> > > some code that was added since its last release.  In the past when I
> > > have started a refactoring on a codebase that has had a long fairly
> > > stable period, but no release, I add a PRE_SOME_CHANGE type of tag. 
> > If
> > > I added such a tag to dbcp should I expect that it will persist
> > > "forever"?  In httpd, I see tags that start with the developer name.
> > > Presumably, it is then up to that developer to remove the tag, if they
> > > no longer require it; and others should leave it alone.  Are such
> > > developer tags acceptable in jakarta-commons?  Would non-release tags
> > be
> > > better marked by the developer that made it, or should more generic
> > > names be used?
> > >
> > > If I were to create a PRE_SOME_CHANGE tag, I would be inclined to
> > leave
> > > it for posterity, in the event someone else had started depending on
> > it,
> > > and would expect others to leave it alone as well.  But if it was
> > > JMCNALLY_1, I would remove it as soon as I was able to move to a
> > > released state and it would give others the ability to contact me if
> > > they wondered if the tag had outlived its usefulness.
> > >
> > > john mcnally
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > 
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message