commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject Re: non-release (vendor/developer) tags
Date Tue, 08 Jul 2003 18:56:59 GMT
I don't see a problem with non-release tags. This is effectively the same
as what the Struts team does when we tag our Commons dependencies prior
to a milestone release.

My preference would be not to have JMCNALLY or MARTINC tags, but rather
have tags that are meaningful to others. Your PRE_SOME_CHANGE tag would
fall into the latter category, assuming the actual name reflected the
nature of the subsequent changes.

--
Martin Cooper


On Mon, 7 Jul 2003, John McNally wrote:

> 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


Mime
View raw message