Is there an missing bit in the instructions for making a release?

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Is there an missing bit in the instructions for making a release?

James Carman
On Fri, Apr 15, 2016 at 12:57 PM James Carman <[hidden email]>
wrote:

> On Fri, Apr 15, 2016 at 12:53 PM sebb <[hidden email]> wrote:
>
>> That is effectively what the final release tag is.
>> We vote on the RC tag, and create the release tag from the successful RC
>> tag.
>>
>>
> Yep, we're not far off.  What I'm proposing is that we try to use the
> Maven Release Plugin to create our releases and push them to a staging
> repository in Nexus for a vote.  If the vote fails, drop the staging repo.
> If we truly want immutable tags, then maybe we just create the release with
> a tag of "foo-1.2.3-rc1" (as someone has pointed out, the release plugin
> can do) and then once (or if) it passes, copy it to "releases/foo-1.2.3".
> I must admit, I haven't RM'd a release in a while, mainly because I found
> it to be extremely painful.  Anything we can do to make that process easier
> could only help us release more often.  Obviously we can't sacrifice
> traceability of the code, but I think we can find a workable solution.
>

Again, we can just stick to the regular process and just "burn" version
numbers for votes that don't pass.  Versions != releases.
Reply | Threaded
Open this post in threaded view
|

Re: Is there an missing bit in the instructions for making a release?

sebb-2-2
On 15 April 2016 at 17:59, James Carman <[hidden email]> wrote:

> On Fri, Apr 15, 2016 at 12:57 PM James Carman <[hidden email]>
> wrote:
>
>> On Fri, Apr 15, 2016 at 12:53 PM sebb <[hidden email]> wrote:
>>
>>> That is effectively what the final release tag is.
>>> We vote on the RC tag, and create the release tag from the successful RC
>>> tag.
>>>
>>>
>> Yep, we're not far off.  What I'm proposing is that we try to use the
>> Maven Release Plugin to create our releases and push them to a staging
>> repository in Nexus for a vote.  If the vote fails, drop the staging repo.
>> If we truly want immutable tags, then maybe we just create the release with
>> a tag of "foo-1.2.3-rc1" (as someone has pointed out, the release plugin
>> can do) and then once (or if) it passes, copy it to "releases/foo-1.2.3".
>> I must admit, I haven't RM'd a release in a while, mainly because I found
>> it to be extremely painful.  Anything we can do to make that process easier
>> could only help us release more often.  Obviously we can't sacrifice
>> traceability of the code, but I think we can find a workable solution.
>>
>
> Again, we can just stick to the regular process

"the regular process" is what is under discussion.

In my experience the Commons "regular process" means an immutable
release tag created from the RC tag.

> and just "burn" version
> numbers for votes that don't pass.  Versions != releases.

Skipping versions has consequences.
For example @since markers, JIRA Fix versions etc.
It's confusing if these relate to versions that were never released;
the alternative is to fix them. More work.

So it would be better not to abandon versions.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is there an missing bit in the instructions for making a release?

Jörg Schaible
In reply to this post by Ralph Goers
Benson Margulies wrote:

> On Fri, Apr 15, 2016 at 11:54 AM, Ralph Goers
> <[hidden email]> wrote:
>> Actually Benson, you can specify the tag name to use when you run the
>> release plugin.  release:prepare has a tag parameter.
>
> Thank you for addressing the specifics. If the -D for that had been in
> the web page to begin with, we would have been spared all this email.

The tag name is also used for the SCM final URLs. Hen and egg.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is there an missing bit in the instructions for making a release?

Ralph Goers
You are correct but I don’t see that as a big deal.  See http://wiki.apache.org/logging/Log4j2ReleaseGuide <http://wiki.apache.org/logging/Log4j2ReleaseGuide> and http://logging.apache.org/log4j/2.x/source-repository.html <http://logging.apache.org/log4j/2.x/source-repository.html>. The fact that the source repository page takes you to the rc tag even though step 13a creates a new tag without the rc doesn’t bother me in the least.

Ralph

> On Apr 15, 2016, at 11:16 AM, Jörg Schaible <[hidden email]> wrote:
>
> Benson Margulies wrote:
>
>> On Fri, Apr 15, 2016 at 11:54 AM, Ralph Goers
>> <[hidden email]> wrote:
>>> Actually Benson, you can specify the tag name to use when you run the
>>> release plugin.  release:prepare has a tag parameter.
>>
>> Thank you for addressing the specifics. If the -D for that had been in
>> the web page to begin with, we would have been spared all this email.
>
> The tag name is also used for the SCM final URLs. Hen and egg.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Is there an missing bit in the instructions for making a release?

garydgregory
In reply to this post by sebb-2-2
On Fri, Apr 15, 2016 at 10:43 AM, sebb <[hidden email]> wrote:

> On 15 April 2016 at 17:59, James Carman <[hidden email]>
> wrote:
> > On Fri, Apr 15, 2016 at 12:57 PM James Carman <
> [hidden email]>
> > wrote:
> >
> >> On Fri, Apr 15, 2016 at 12:53 PM sebb <[hidden email]> wrote:
> >>
> >>> That is effectively what the final release tag is.
> >>> We vote on the RC tag, and create the release tag from the successful
> RC
> >>> tag.
> >>>
> >>>
> >> Yep, we're not far off.  What I'm proposing is that we try to use the
> >> Maven Release Plugin to create our releases and push them to a staging
> >> repository in Nexus for a vote.  If the vote fails, drop the staging
> repo.
> >> If we truly want immutable tags, then maybe we just create the release
> with
> >> a tag of "foo-1.2.3-rc1" (as someone has pointed out, the release plugin
> >> can do) and then once (or if) it passes, copy it to
> "releases/foo-1.2.3".
> >> I must admit, I haven't RM'd a release in a while, mainly because I
> found
> >> it to be extremely painful.  Anything we can do to make that process
> easier
> >> could only help us release more often.  Obviously we can't sacrifice
> >> traceability of the code, but I think we can find a workable solution.
> >>
> >
> > Again, we can just stick to the regular process
>
> "the regular process" is what is under discussion.
>
> In my experience the Commons "regular process" means an immutable
> release tag created from the RC tag.
>
> > and just "burn" version
> > numbers for votes that don't pass.  Versions != releases.
>

Burning versions would be a sign of a failure in our release process IMO.
Maven does this release burning still today. I am against it.

A tag should be created for all RCs to easily track what we vote on.
Granted that voting on a SVN revision or Git hash should provide the same
info.

Gary

>
> Skipping versions has consequences.
> For example @since markers, JIRA Fix versions etc.
> It's confusing if these relate to versions that were never released;
> the alternative is to fix them. More work.
>
> So it would be better not to abandon versions.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: Is there an missing bit in the instructions for making a release?

James Carman
In reply to this post by sebb-2-2
On Fri, Apr 15, 2016 at 1:43 PM sebb <[hidden email]> wrote:

>
> "the regular process" is what is under discussion.
>
>
I meant the regular process used by the maven release plugin.  :)  That's
"regular" to me, because that's what I use all the time.  I think we have
an opportunity to streamline what we do here quite a bit.  One of the main
issues we have here is the assertion that tags must be immutable.  We have
two options that I can see, then (since folks are opposed to "burning"
version numbers):

1.  Make them mutable.  Then we can delete the tags when a release VOTE
fails and go at it again.
2.  Let the maven release plugin create  tags called "rc/foo-1.2.3-rc1" or
whatever while it's staging a release to Nexus for us.  Then, when the
release VOTE passes, we release the staging repository and copy the "rc"
tag to "releases/foo-1.2.3" and call it a day.

Thoughts?
Reply | Threaded
Open this post in threaded view
|

Re: Is there an missing bit in the instructions for making a release?

garydgregory
On Fri, Apr 15, 2016 at 12:52 PM, James Carman <[hidden email]>
wrote:

> On Fri, Apr 15, 2016 at 1:43 PM sebb <[hidden email]> wrote:
>
> >
> > "the regular process" is what is under discussion.
> >
> >
> I meant the regular process used by the maven release plugin.  :)  That's
> "regular" to me, because that's what I use all the time.  I think we have
> an opportunity to streamline what we do here quite a bit.  One of the main
> issues we have here is the assertion that tags must be immutable.  We have
> two options that I can see, then (since folks are opposed to "burning"
> version numbers):
>
> 1.  Make them mutable.  Then we can delete the tags when a release VOTE
> fails and go at it again.
> 2.  Let the maven release plugin create  tags called "rc/foo-1.2.3-rc1" or
> whatever while it's staging a release to Nexus for us.  Then, when the
> release VOTE passes, we release the staging repository and copy the "rc"
> tag to "releases/foo-1.2.3" and call it a day.
>

I always copy the RC tag to a release tag when I RM.

Gary


> Thoughts?
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: Is there an missing bit in the instructions for making a release?

sebb-2-2
On 15 April 2016 at 21:08, Gary Gregory <[hidden email]> wrote:

> On Fri, Apr 15, 2016 at 12:52 PM, James Carman <[hidden email]>
> wrote:
>
>> On Fri, Apr 15, 2016 at 1:43 PM sebb <[hidden email]> wrote:
>>
>> >
>> > "the regular process" is what is under discussion.
>> >
>> >
>> I meant the regular process used by the maven release plugin.  :)  That's
>> "regular" to me, because that's what I use all the time.  I think we have
>> an opportunity to streamline what we do here quite a bit.  One of the main
>> issues we have here is the assertion that tags must be immutable.  We have
>> two options that I can see, then (since folks are opposed to "burning"
>> version numbers):
>>
>> 1.  Make them mutable.  Then we can delete the tags when a release VOTE
>> fails and go at it again.

As already explained, this is not possible with Git.
Infra have disabled updating of certain tags includig the ones used
for releases.

We should have the same rules for SVN and Git components.

>> 2.  Let the maven release plugin create  tags called "rc/foo-1.2.3-rc1" or
>> whatever while it's staging a release to Nexus for us.  Then, when the
>> release VOTE passes, we release the staging repository and copy the "rc"
>> tag to "releases/foo-1.2.3" and call it a day.

OK by me.

>
> I always copy the RC tag to a release tag when I RM.

But what does your POM contain?

> Gary
>
>
>> Thoughts?
>>
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is there an missing bit in the instructions for making a release?

James Carman
On Fri, Apr 15, 2016 at 4:13 PM sebb <[hidden email]> wrote:

>
> As already explained, this is not possible with Git.
> Infra have disabled updating of certain tags includig the ones used
> for releases.


Sorry, didn't realize if this was something we imposed on ourselves and
asked infra to do for us or if it was an ASF-wide policy.  I like "audit
trail" aspect of keeping the "rc" tags around (as Gary pointed out
elsethread).  Looks like some variation of my "option 2" is still on the
table, then.
Reply | Threaded
Open this post in threaded view
|

Re: Is there an missing bit in the instructions for making a release?

sebb-2-2
On 15 April 2016 at 21:27, James Carman <[hidden email]> wrote:

> On Fri, Apr 15, 2016 at 4:13 PM sebb <[hidden email]> wrote:
>
>>
>> As already explained, this is not possible with Git.
>> Infra have disabled updating of certain tags includig the ones used
>> for releases.
>
>
> Sorry, didn't realize if this was something we imposed on ourselves and
> asked infra to do for us or if it was an ASF-wide policy.  I like "audit
> trail" aspect of keeping the "rc" tags around (as Gary pointed out
> elsethread).  Looks like some variation of my "option 2" is still on the
> table, then.

Is it possible to tell the release plugin to create the actual tag as
IO-1.2.3-RC4 but store the SCM tags in the POM as IO-1.2.3 ?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12