tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [VOTE] Release build 6.0.28
Date Thu, 08 Jul 2010 16:57:46 GMT
On Thu, Jul 8, 2010 at 9:36 AM, sebb <sebbaz@gmail.com> wrote:
> On 8 July 2010 16:22, Henri Yandell <flamefew@gmail.com> wrote:
>>
>> IIUC, it means the tag would not refer to any trunk revision.
>
> Strictly speaking, yes, there is no exact match in trunk, because the
> version fixes are deliberately not applied to trunk.
>
>> It gets around having a commit to a tag by hiding the change in the copy.
>
> Sort of. The changes are not hidden, they are shown in the commit e-mail.

e-mails are fairly worthless though. The issue for me is that while it
is in the svn log history, it's in a trunk->tag copy that many will
assume is an atomic step.

Immutability of tags vs atomic commits.

>> I'd rather get over the notion that tags can't be modified than be tagging uncommitted
code.
>
> All the code is committed; it's just not all in trunk.
>
> However, if you modify the tag after creation as you suggest, again
> the revisions to the tag won't appear in trunk.
>
> AFAICT, the only way to ensure that a tag corresponds to a trunk
> revision is to tag from trunk and then never change the tag =>
> immutable tag.

Agreed; but not agreed on it being important. The need for a tag to
point to a trunk revision is an arbitrary invention of our development
process; instead:

* Create release branch.
* Develop on release branch.
* Declare release branch releaseable [vote].
* 'Tag' by making release branch read-only. In SVN terms, mv the
release branch from 7.0.0-release to 7.0.0.

Not saying that's great, just that issue may be in how we're defining
the problem.

> The end result of the method I propose is similar to creating the tag
> and then updating it, but it's easier to spot violations, because a
> tag should only appear the once, and never in an update commit.

But obscures history. I may be weird - I seem to spend a lot of my
time in source control history so care a lot about keeping it simple.

Also I'm bikeshedding - I've not been a Tomcat release manager, so
there may be details that differ from my experience elsewhere.

Hen

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


Mime
View raw message