You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Paul Davis <pa...@gmail.com> on 2011/06/16 02:04:01 UTC
Preparing the 1.0.3 release.
I'm officially kicking of the 1.0.3 release procedure.
Everyone should double check the NEWS and CHANGES files and tell me
that everything is ok on that end. Then you should vote whether to
continue along with things. I'll be making a dry run of rolling the
tarball tonight and tomorrow I'll start off the actual release vote
baring any concerns.
POSSIBLE RELEASE PROCEDURE UPDATE:
During the 1.0.2 release it became apparent that when a vote fails and
we have to redo the whole thing that it can become confusing what's
being voted on as there exists multiple tarballs that have the same
filename. It was suggested during the last round that we adopt an rc1,
rc2... style strategy. This is all fine and good. Tags and release
names can be managed easily enough, but it brings up a question.
How do we go from the final rcN candidate to an actual release?
My first thought was to update acinclude.m4.in so that the names are
all automagical. The downfall of this is that the rcN is contained
*inside* the tarball which affects the signatures. That's significant
because in theory we're supposed to be voting "on the exact tarball
that becomes version x.y.z".
The obvious thing to do otherwise would be to just rename the tarball
and signatures after running make distsign, but that's kind of a lie
because when you build and run the artifact it won't have the correct
version.
Anyway, I don't want this to be a bikeshed before a 1.0.3 release so
if it becomes one I'll veto the idea and pretend I never suggested it.
Humbly yours,
Igor the Release Manager
Re: Preparing the 1.0.3 release.
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, Jun 15, 2011 at 17:04, Paul Davis <pa...@gmail.com> wrote:
> I'm officially kicking of the 1.0.3 release procedure.
>
> Everyone should double check the NEWS and CHANGES files and tell me
> that everything is ok on that end. Then you should vote whether to
> continue along with things. I'll be making a dry run of rolling the
> tarball tonight and tomorrow I'll start off the actual release vote
> baring any concerns.
+1 to continuing with the release. Yay.
Re: Preparing the 1.0.3 release.
Posted by Noah Slater <ns...@apache.org>.
On 16 Jun 2011, at 02:32, Benoit Chesneau wrote:
> On Wednesday, June 15, 2011, Noah Slater <ns...@apache.org> wrote:
>>
>> On 16 Jun 2011, at 01:48, Dave Cottlehuber wrote:
>>
>>> & to avoid any confusion teh Dark Lord is nslater, not me.
>>
>> When you say my name, I can see your location.
>>
>> (I'm in negotiations with Apple about licensing this technology.)
>>
>>
> you mean to have the rights on your technology ?
Naturally.
Re: Preparing the 1.0.3 release.
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wednesday, June 15, 2011, Noah Slater <ns...@apache.org> wrote:
>
> On 16 Jun 2011, at 01:48, Dave Cottlehuber wrote:
>
>> & to avoid any confusion teh Dark Lord is nslater, not me.
>
> When you say my name, I can see your location.
>
> (I'm in negotiations with Apple about licensing this technology.)
>
>
you mean to have the rights on your technology ?
Re: Preparing the 1.0.3 release.
Posted by Noah Slater <ns...@apache.org>.
On 16 Jun 2011, at 01:48, Dave Cottlehuber wrote:
> & to avoid any confusion teh Dark Lord is nslater, not me.
When you say my name, I can see your location.
(I'm in negotiations with Apple about licensing this technology.)
Re: Preparing the 1.0.3 release.
Posted by Dave Cottlehuber <da...@muse.net.nz>.
On 16 June 2011 12:47, Noah Slater <ns...@apache.org> wrote:
>
> On 16 Jun 2011, at 01:33, Dave Cottlehuber wrote:
>
>>> Sound like a good compromise, my dark lord?
>>>
>>
>> +1.
>
> +1 from me as well.
>
>
& to avoid any confusion teh Dark Lord is nslater, not me.
<kshhhh>
<kssshh>
<kshhhh>
Re: Preparing the 1.0.3 release.
Posted by Noah Slater <ns...@apache.org>.
On 16 Jun 2011, at 01:33, Dave Cottlehuber wrote:
>> Sound like a good compromise, my dark lord?
>>
>
> +1.
+1 from me as well.
Re: Preparing the 1.0.3 release.
Posted by Dave Cottlehuber <da...@muse.net.nz>.
On 16 June 2011 12:17, Paul Davis <pa...@gmail.com> wrote:
> On Wed, Jun 15, 2011 at 8:09 PM, Noah Slater <ns...@apache.org> wrote:
>>
>> On 16 Jun 2011, at 01:04, Paul Davis wrote:
>>
>>> During the 1.0.2 release it became apparent that when a vote fails and
>>> we have to redo the whole thing that it can become confusing what's
>>> being voted on as there exists multiple tarballs that have the same
>>> filename.
>>
>> I didn't see any mention of this?
>>
>> And anyway, it is only on the local machine.
>>
>> The original release artefacts should be replaced in their entirety.
>>
>> There is no way we can modify the release artefacts in any way between them being voted on and them being released, so the idea of baking in a rcX is completely out of the question. The only possibility I can think of is to prefix the files in an rcX directory in the release managers personal directory. However, it is my opinion that this is not so much of a problem as to warrant such a move. We've managed the last few years without this. Perhaps better instructions in the vote emails could help matters?
>
> Yeah, the absolutely no modifications bit seemed like it'd almost make
> this sort of a no go.
>
> There was minor chatter last time in confusion about which artefacts
> were what because everything had the same filenames as I replaced
> things in my people.a.o/~davisp/dist/1.0.3 directory.
>
> I think I might just steal your idea and in my dist directory do
> something like ~davisp/dist/1.0.3-rc1/ and the files are all as
> before.
>
> Sound like a good compromise, my dark lord?
>
+1.
Re: Preparing the 1.0.3 release.
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Jun 15, 2011 at 8:09 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 16 Jun 2011, at 01:04, Paul Davis wrote:
>
>> During the 1.0.2 release it became apparent that when a vote fails and
>> we have to redo the whole thing that it can become confusing what's
>> being voted on as there exists multiple tarballs that have the same
>> filename.
>
> I didn't see any mention of this?
>
> And anyway, it is only on the local machine.
>
> The original release artefacts should be replaced in their entirety.
>
> There is no way we can modify the release artefacts in any way between them being voted on and them being released, so the idea of baking in a rcX is completely out of the question. The only possibility I can think of is to prefix the files in an rcX directory in the release managers personal directory. However, it is my opinion that this is not so much of a problem as to warrant such a move. We've managed the last few years without this. Perhaps better instructions in the vote emails could help matters?
Yeah, the absolutely no modifications bit seemed like it'd almost make
this sort of a no go.
There was minor chatter last time in confusion about which artefacts
were what because everything had the same filenames as I replaced
things in my people.a.o/~davisp/dist/1.0.3 directory.
I think I might just steal your idea and in my dist directory do
something like ~davisp/dist/1.0.3-rc1/ and the files are all as
before.
Sound like a good compromise, my dark lord?
Re: Preparing the 1.0.3 release.
Posted by Noah Slater <ns...@apache.org>.
On 16 Jun 2011, at 01:04, Paul Davis wrote:
> During the 1.0.2 release it became apparent that when a vote fails and
> we have to redo the whole thing that it can become confusing what's
> being voted on as there exists multiple tarballs that have the same
> filename.
I didn't see any mention of this?
And anyway, it is only on the local machine.
The original release artefacts should be replaced in their entirety.
There is no way we can modify the release artefacts in any way between them being voted on and them being released, so the idea of baking in a rcX is completely out of the question. The only possibility I can think of is to prefix the files in an rcX directory in the release managers personal directory. However, it is my opinion that this is not so much of a problem as to warrant such a move. We've managed the last few years without this. Perhaps better instructions in the vote emails could help matters?