couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Tweaking the release procedure
Date Wed, 19 Oct 2011 17:33:44 GMT
On Wed, Oct 19, 2011 at 12:28 PM, Adam Kocoloski <kocolosk@apache.org> wrote:
> Paul, +1 to the broad strokes, but I'm a little confused about the specifics.  Do you
really want branch names to start with "branches/" and tag names to start with "tags/"?  Or
is that just a bit of abstraction leakage from the git internals?
>

Sorry, yeah. Before I had those it was a bit confusing between
"rel/1.1.1" and "rel/1.1.x" where one is actually an internal name of
"refs/tags/rel/1.1.1" and the other is "refs/branches/rel/1.1.x". Just
wanted to make that more apparent.

> Branch names like rel/1.1.x for non-rewriteable release branches are fine by me.  Tags
like rc/1.1.1rc1 and rel/1.1.1 I'm not so excited about.  Are you trying to use those prefixes
to enforce that the tags are immutable?  If so, then I guess it makes sense, though maybe
we don't need to repeat ourselves and instead use rc/1.1.1-1.
>

Well, the rel/ prefix is for the pattern match to enforce the
non-rewriting part. The rc/ is just convention and would  be
rewritable. Or we could just disallow rewriting of any tag and then
have "1.1.1-rc1" "1.1.1-rc2" "1.1.1" etc etc. I don't have a huge
investment in the rel/ prefix by any means. Was just considering that
we have the capability so wondering if people would want to use it.

> Bob, I think it's a good thing that copying the accepted release candidate to the final
release tag preserves the relationship between the two things.  I don't find it off-putting
at all.
>

+1

> Thanks for getting this discussion going guys.
>
> Adam
>
> On Oct 19, 2011, at 1:11 PM, Robert Newson wrote:
>
>> I like it, +1.
>>
>> I'll note that the copied tag '1.1.1' from '1.1.1rc1' will look a
>> little strange. It will be exactly the same as the '1.1.1rc1' tag,
>> including *saying* 'tag 1.1.1rc1' in the tag body (when you view it
>> with git tag -v 1.1.1, for example). I'm fine with that, it's pointing
>> at the same stuff and it's a record of the fact that rc1 was blessed
>> as the actual release, but I mention it because it's odd.
>>
>> B.
>>
>> On 19 October 2011 17:55, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>>> Devs,
>>>
>>> Now that we're on Git and have a system for managing tags that isn't
>>> nutty, its time that we should revisit our tagging protocol for
>>> releases.
>>>
>>> First, a note about the Git hosting. One of the ASF requests was that
>>> I write a thing that prevented the ability of rewriting history on
>>> master. When I implemented this I made the branch pattern configurable
>>> to multiple branches. Currently this protection applies to master,
>>> trunk, and any branch or tag prefixed with "rel/". The idea was that
>>> we'd be able to move release branches like 1.1.x, 1.2.x etc to
>>> rel/1.1.x and rel/1.2.x so that we don't accidentally break them. The
>>> same for tags. Once we tag something as rel/1.1.1 the rewrite checks
>>> will prevent someone from accidentally modifying it.
>>>
>>> So given that, and the fact that Git lets us alias specific tags
>>> exactly, I thought I'd propose a couple slight tweaks to the release
>>> procedure.
>>>
>>> 1. When tagging release candidates, the tag would be of the pattern:
>>>
>>>     tags/rc/X.Y.Z-rcN
>>>
>>> 2. When a release formally passes a vote, we would copy the tag to:
>>>
>>>     tags/rel/X.Y.Z
>>>
>>> 3. I think we discussed this before, but we should also place the rc
>>> artefacts into a directory named as such (IIRC, we decided that the
>>> name shouldn't change). Ie, 1.1.1 would be stored at:
>>> http://people.apache.org/~rnewson/dist/1.1.1/rc1/apache-couchdb-1.1.1.tar.gz
>>>
>>> 4. Making new release branches we should name them:
>>>
>>>    branches/rel/X.Y.x
>>>
>>> 5. For continuity, I'd also propose copying all of our older tags and
>>> branches to the new pattern (while keeping the current versions around
>>> for an extended period of time).
>>>
>>> Thoughts?
>>>
>
>

Mime
View raw message