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
|

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

Benson Margulies
The instructions offer two approaches as equivalent: manual tagging
and pom-editing, and the release plugin.

If you just use the default options and hit <enter> a few times,
you'll get the tag: commons-io-2.5, NOT commons-io-2.5-RCx. The manual
process will, on the other hand, name the tag commons-io-2.5-RCx.

It seems to me that the doc should mention this.

---------------------------------------------------------------------
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?

Benson Margulies
On Thu, Apr 14, 2016 at 9:09 AM, Benson Margulies <[hidden email]> wrote:
> The instructions offer two approaches as equivalent: manual tagging
> and pom-editing, and the release plugin.
>
> If you just use the default options and hit <enter> a few times,
> you'll get the tag: commons-io-2.5, NOT commons-io-2.5-RCx. The manual
> process will, on the other hand, name the tag commons-io-2.5-RCx.
>
> It seems to me that the doc should mention this.

However, there's more. The SCM elements in the pom will refer to the
RC tag, which is not what you want once the release is finalized. So I
think that the release plugin procedure has to be to let it create the
commons-io-2.5 tag, and then manually add the -RCx tag for the record.

---------------------------------------------------------------------
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?

sebb-2-2
On 14 April 2016 at 14:11, Benson Margulies <[hidden email]> wrote:

> On Thu, Apr 14, 2016 at 9:09 AM, Benson Margulies <[hidden email]> wrote:
>> The instructions offer two approaches as equivalent: manual tagging
>> and pom-editing, and the release plugin.
>>
>> If you just use the default options and hit <enter> a few times,
>> you'll get the tag: commons-io-2.5, NOT commons-io-2.5-RCx. The manual
>> process will, on the other hand, name the tag commons-io-2.5-RCx.
>>
>> It seems to me that the doc should mention this.
>
> However, there's more. The SCM elements in the pom will refer to the
> RC tag, which is not what you want once the release is finalized. So I
> think that the release plugin procedure has to be to let it create the
> commons-io-2.5 tag, and then manually add the -RCx tag for the record.

-1

That sounds backwards.

The commons-io-2.5 tag should only be created when the RCn vote has succeeded.
It is created by copying the successful RCn tag.

If you create the 2.5 tag first, and create RCn from it,what happens
when the RCn vote fails or is withdrawn?
That implies the 2.5 tag will have to be deleted and recreated.
But tags are supposed to be immutable.

I don't use the Maven Release plugin myself, partly because of such issues.
But others who do may be able to clarify the instructions.

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

---------------------------------------------------------------------
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?

Benson Margulies
On Thu, Apr 14, 2016 at 5:47 PM, sebb <[hidden email]> wrote:

> On 14 April 2016 at 14:11, Benson Margulies <[hidden email]> wrote:
>> On Thu, Apr 14, 2016 at 9:09 AM, Benson Margulies <[hidden email]> wrote:
>>> The instructions offer two approaches as equivalent: manual tagging
>>> and pom-editing, and the release plugin.
>>>
>>> If you just use the default options and hit <enter> a few times,
>>> you'll get the tag: commons-io-2.5, NOT commons-io-2.5-RCx. The manual
>>> process will, on the other hand, name the tag commons-io-2.5-RCx.
>>>
>>> It seems to me that the doc should mention this.
>>
>> However, there's more. The SCM elements in the pom will refer to the
>> RC tag, which is not what you want once the release is finalized. So I
>> think that the release plugin procedure has to be to let it create the
>> commons-io-2.5 tag, and then manually add the -RCx tag for the record.
>
> -1
>
> That sounds backwards.
>
> The commons-io-2.5 tag should only be created when the RCn vote has succeeded.
> It is created by copying the successful RCn tag.


Sebb, I'm just following the doc as I read it. It tells me that I have
the option to run release:prepare. Release:prepare creates the tag you
don't like. There is no way to use that goal of that plugin that
avoids it; if you try, you end up with the wrong pom contents for the
actual release, and then you can't keep the signatures consistent.

What I did, in fact, was 'svn cp commons-io-2.5 commons-io-2.5-RC4'.
If you like, I could svn rm the plain commons-io-2.5 tag until and
unless a vote passes, and then cp/mv from the RC tag to it to put it
back at that point.

The doc reminds people over and over again that tags are, in fact,
_not_ immutable, which is why the email template carefully calls for
svn rev numbers. Tags aren't immutable in svn, and not in git,
neither. Every Apache project I've RM'd takes that into account.
People are constantly removing and recreating tags as votes fail and
succeed. If this PMC doesn't want to do that, it needs different
documentation.

If you think that no one should ever use the maven-release-plugin on
the commons project, than as a PMC member, why don't you commit a
change to the doc to take it away as a procedural option, instead of
-1'ing me for following the doc?  If the doc said, 'you must do all
the pom editing and tagging by hand', I'd have gritted my teeth at the
tedium, but I would have done it.



>
> If you create the 2.5 tag first, and create RCn from it,what happens
> when the RCn vote fails or is withdrawn?
> That implies the 2.5 tag will have to be deleted and recreated.
> But tags are supposed to be immutable.
>
> I don't use the Maven Release plugin myself, partly because of such issues.
> But others who do may be able to clarify the instructions.
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
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?

sebb-2-2
On 15 April 2016 at 01:27, Benson Margulies <[hidden email]> wrote:

> On Thu, Apr 14, 2016 at 5:47 PM, sebb <[hidden email]> wrote:
>> On 14 April 2016 at 14:11, Benson Margulies <[hidden email]> wrote:
>>> On Thu, Apr 14, 2016 at 9:09 AM, Benson Margulies <[hidden email]> wrote:
>>>> The instructions offer two approaches as equivalent: manual tagging
>>>> and pom-editing, and the release plugin.
>>>>
>>>> If you just use the default options and hit <enter> a few times,
>>>> you'll get the tag: commons-io-2.5, NOT commons-io-2.5-RCx. The manual
>>>> process will, on the other hand, name the tag commons-io-2.5-RCx.
>>>>
>>>> It seems to me that the doc should mention this.
>>>
>>> However, there's more. The SCM elements in the pom will refer to the
>>> RC tag, which is not what you want once the release is finalized. So I
>>> think that the release plugin procedure has to be to let it create the
>>> commons-io-2.5 tag, and then manually add the -RCx tag for the record.
>>
>> -1
>>
>> That sounds backwards.
>>
>> The commons-io-2.5 tag should only be created when the RCn vote has succeeded.
>> It is created by copying the successful RCn tag.
>
>
> Sebb, I'm just following the doc as I read it. It tells me that I have
> the option to run release:prepare. Release:prepare creates the tag you
> don't like. There is no way to use that goal of that plugin that
> avoids it; if you try, you end up with the wrong pom contents for the
> actual release, and then you can't keep the signatures consistent.
>
> What I did, in fact, was 'svn cp commons-io-2.5 commons-io-2.5-RC4'.

Does the doc tell you to do that?
Did commons-io-2.5 exist previously, i.e. did the previous RM create it?

> If you like, I could svn rm the plain commons-io-2.5 tag until and
> unless a vote passes, and then cp/mv from the RC tag to it to put it
> back at that point.

AFAIK others have used the Maven Release goal without prematurely
creating the final tag.
I have never used it so I don't know how they managed it.

But if the only proper way to use the release plugin results in
creating the final tag before the vote has even started, then the
plugin is more seriously broken than I thought.

> The doc reminds people over and over again that tags are, in fact,
> _not_ immutable, which is why the email template carefully calls for
> svn rev numbers. Tags aren't immutable in svn, and not in git,
> neither. Every Apache project I've RM'd takes that into account.
> People are constantly removing and recreating tags as votes fail and
> succeed. If this PMC doesn't want to do that, it needs different
> documentation.

My point was that the final tag should be immutable; it should only be
created once and then left alone.
RC tags also should only be created once.

Immutability is achieved by convention.

> If you think that no one should ever use the maven-release-plugin on
> the commons project, than as a PMC member, why don't you commit a
> change to the doc to take it away as a procedural option, instead of
> -1'ing me for following the doc?  If the doc said, 'you must do all
> the pom editing and tagging by hand', I'd have gritted my teeth at the
> tedium, but I would have done it.

Because others want to use the plugin and AFAIK have successfully used
it without prematurely creating the final tag.

>
>
>>
>> If you create the 2.5 tag first, and create RCn from it,what happens
>> when the RCn vote fails or is withdrawn?
>> That implies the 2.5 tag will have to be deleted and recreated.
>> But tags are supposed to be immutable.
>>
>> I don't use the Maven Release plugin myself, partly because of such issues.
>> But others who do may be able to clarify the instructions.
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
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?

Benson Margulies
Sebb,

I don't know why you think I could distinguish the following possible
behaviors of prior RMs with a reasonable level of effort:

1: didn't use the maven-release-plugin
2: did use the maven-release-plugin and then used svn mvn to rename
the tag it created
3: did use the maven-release-plugin, typed 'commons-io-2.x-RCy' at the
prompt, and released with a pom with an incorrect scm element.
4: something else I didn't think of.

I didn't volunteer to be an archaeologist, I volunteered to be a
release manager..

At best, the doc is, as I wrote to start this conversation,
incomplete, in that it does not give specific instructions for
achieving the PMC's goals using the plugin.

To me, the following sequence is inoffensive:

1: run release:prepare, creating a premature 'real' tag.
2: svn mv to convert that tag to an -RC tag.
3: svn mv again to convert it to a (conventionally) immutable 'real
tag' if the vote passes.

However, what I find inoffensive isn't important here. I'm not a PMC
member here. If this PMC has a strong policy of tag immutability, then
this PMC needs to document a procedure that both treats tags as
immutable and creates completely correct poms, including the scm
element that has to anticipate the eventual tag. It could create that
policy by erasing any mention of release:prepare, or by filling in the
missing details (though I continue to believe that there is no way to
make it come out the way you want.)

Believe me, if I ever RM another commons release, I won't use
release:prepare until and unless someone writes up a step-by-step
guide that leads me to do so in an acceptable way.

If you examine the 'tags' directory in svn right now, you will see
that it contains what I believe that you want it to contain: no
commons-io-2.5 tag, but rather a commons-io-2.5-RC4 tag. So, I
respectfully submit that we could proceed to decide if this release is
good enough, and sort out the documentation later.

---------------------------------------------------------------------
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?

sebb-2-2
On 15 April 2016 at 02:19, Benson Margulies <[hidden email]> wrote:
> Sebb,
>
> I don't know why you think I could distinguish the following possible
> behaviors of prior RMs with a reasonable level of effort:

As I have already said, I don't use the plugin.
However I have followed release votes and AFAICR the final tag never
been created before the vote completed.
In all cases I can remember, the final tag is created once the vote
has completed.
And I am pretty certain other RMs have used the release plugin.

So it seems clear to me that something has gone wrong here.

I don't know what, so I think we need input from an RM who has used
the release plugin.
They should be able to point out what is missing from the instructions.

> 1: didn't use the maven-release-plugin
> 2: did use the maven-release-plugin and then used svn mvn to rename
> the tag it created
> 3: did use the maven-release-plugin, typed 'commons-io-2.x-RCy' at the
> prompt, and released with a pom with an incorrect scm element.
> 4: something else I didn't think of.
>
> I didn't volunteer to be an archaeologist, I volunteered to be a
> release manager..
>
> At best, the doc is, as I wrote to start this conversation,
> incomplete, in that it does not give specific instructions for
> achieving the PMC's goals using the plugin.
>
> To me, the following sequence is inoffensive:
>
> 1: run release:prepare, creating a premature 'real' tag.
> 2: svn mv to convert that tag to an -RC tag.
> 3: svn mv again to convert it to a (conventionally) immutable 'real
> tag' if the vote passes.
>
> However, what I find inoffensive isn't important here. I'm not a PMC
> member here. If this PMC has a strong policy of tag immutability, then
> this PMC needs to document a procedure that both treats tags as
> immutable and creates completely correct poms, including the scm
> element that has to anticipate the eventual tag. It could create that
> policy by erasing any mention of release:prepare, or by filling in the
> missing details (though I continue to believe that there is no way to
> make it come out the way you want.)
>
> Believe me, if I ever RM another commons release, I won't use
> release:prepare until and unless someone writes up a step-by-step
> guide that leads me to do so in an acceptable way.
>
> If you examine the 'tags' directory in svn right now, you will see
> that it contains what I believe that you want it to contain: no
> commons-io-2.5 tag, but rather a commons-io-2.5-RC4 tag. So, I
> respectfully submit that we could proceed to decide if this release is
> good enough, and sort out the documentation later.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
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?

Benson Margulies
On Thu, Apr 14, 2016 at 10:33 PM, sebb <[hidden email]> wrote:

> On 15 April 2016 at 02:19, Benson Margulies <[hidden email]> wrote:
>> Sebb,
>>
>> I don't know why you think I could distinguish the following possible
>> behaviors of prior RMs with a reasonable level of effort:
>
> As I have already said, I don't use the plugin.
> However I have followed release votes and AFAICR the final tag never
> been created before the vote completed.
> In all cases I can remember, the final tag is created once the vote
> has completed.
> And I am pretty certain other RMs have used the release plugin.
>
> So it seems clear to me that something has gone wrong here.
>
> I don't know what, so I think we need input from an RM who has used
> the release plugin.
> They should be able to point out what is missing from the instructions.

This started when I sent email two days ago saying that I was
perplexed by the instructions. I only proceeded when no prior RM, or
anyone else, answered.

Maybe they used -DdryRun=true and then edited. Maybe I'm just being
obtuse. We'll see.



>
>> 1: didn't use the maven-release-plugin
>> 2: did use the maven-release-plugin and then used svn mvn to rename
>> the tag it created
>> 3: did use the maven-release-plugin, typed 'commons-io-2.x-RCy' at the
>> prompt, and released with a pom with an incorrect scm element.
>> 4: something else I didn't think of.
>>
>> I didn't volunteer to be an archaeologist, I volunteered to be a
>> release manager..
>>
>> At best, the doc is, as I wrote to start this conversation,
>> incomplete, in that it does not give specific instructions for
>> achieving the PMC's goals using the plugin.
>>
>> To me, the following sequence is inoffensive:
>>
>> 1: run release:prepare, creating a premature 'real' tag.
>> 2: svn mv to convert that tag to an -RC tag.
>> 3: svn mv again to convert it to a (conventionally) immutable 'real
>> tag' if the vote passes.
>>
>> However, what I find inoffensive isn't important here. I'm not a PMC
>> member here. If this PMC has a strong policy of tag immutability, then
>> this PMC needs to document a procedure that both treats tags as
>> immutable and creates completely correct poms, including the scm
>> element that has to anticipate the eventual tag. It could create that
>> policy by erasing any mention of release:prepare, or by filling in the
>> missing details (though I continue to believe that there is no way to
>> make it come out the way you want.)
>>
>> Believe me, if I ever RM another commons release, I won't use
>> release:prepare until and unless someone writes up a step-by-step
>> guide that leads me to do so in an acceptable way.
>>
>> If you examine the 'tags' directory in svn right now, you will see
>> that it contains what I believe that you want it to contain: no
>> commons-io-2.5 tag, but rather a commons-io-2.5-RC4 tag. So, I
>> respectfully submit that we could proceed to decide if this release is
>> good enough, and sort out the documentation later.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
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?

Brent Worden-2
I probably won't be much help either as I have never used the plugin but,
there is a tag option for the plugin that might help control the SCM tag
that is used.  Of all the options for the plugin listed on
https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html,
the tag* options might meet your needs.


Thanks,

Brent

On Fri, Apr 15, 2016 at 5:16 AM, Benson Margulies <[hidden email]>
wrote:

> On Thu, Apr 14, 2016 at 10:33 PM, sebb <[hidden email]> wrote:
> > On 15 April 2016 at 02:19, Benson Margulies <[hidden email]>
> wrote:
> >> Sebb,
> >>
> >> I don't know why you think I could distinguish the following possible
> >> behaviors of prior RMs with a reasonable level of effort:
> >
> > As I have already said, I don't use the plugin.
> > However I have followed release votes and AFAICR the final tag never
> > been created before the vote completed.
> > In all cases I can remember, the final tag is created once the vote
> > has completed.
> > And I am pretty certain other RMs have used the release plugin.
> >
> > So it seems clear to me that something has gone wrong here.
> >
> > I don't know what, so I think we need input from an RM who has used
> > the release plugin.
> > They should be able to point out what is missing from the instructions.
>
> This started when I sent email two days ago saying that I was
> perplexed by the instructions. I only proceeded when no prior RM, or
> anyone else, answered.
>
> Maybe they used -DdryRun=true and then edited. Maybe I'm just being
> obtuse. We'll see.
>
>
>
> >
> >> 1: didn't use the maven-release-plugin
> >> 2: did use the maven-release-plugin and then used svn mvn to rename
> >> the tag it created
> >> 3: did use the maven-release-plugin, typed 'commons-io-2.x-RCy' at the
> >> prompt, and released with a pom with an incorrect scm element.
> >> 4: something else I didn't think of.
> >>
> >> I didn't volunteer to be an archaeologist, I volunteered to be a
> >> release manager..
> >>
> >> At best, the doc is, as I wrote to start this conversation,
> >> incomplete, in that it does not give specific instructions for
> >> achieving the PMC's goals using the plugin.
> >>
> >> To me, the following sequence is inoffensive:
> >>
> >> 1: run release:prepare, creating a premature 'real' tag.
> >> 2: svn mv to convert that tag to an -RC tag.
> >> 3: svn mv again to convert it to a (conventionally) immutable 'real
> >> tag' if the vote passes.
> >>
> >> However, what I find inoffensive isn't important here. I'm not a PMC
> >> member here. If this PMC has a strong policy of tag immutability, then
> >> this PMC needs to document a procedure that both treats tags as
> >> immutable and creates completely correct poms, including the scm
> >> element that has to anticipate the eventual tag. It could create that
> >> policy by erasing any mention of release:prepare, or by filling in the
> >> missing details (though I continue to believe that there is no way to
> >> make it come out the way you want.)
> >>
> >> Believe me, if I ever RM another commons release, I won't use
> >> release:prepare until and unless someone writes up a step-by-step
> >> guide that leads me to do so in an acceptable way.
> >>
> >> If you examine the 'tags' directory in svn right now, you will see
> >> that it contains what I believe that you want it to contain: no
> >> commons-io-2.5 tag, but rather a commons-io-2.5-RC4 tag. So, I
> >> respectfully submit that we could proceed to decide if this release is
> >> good enough, and sort out the documentation later.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> 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?

sebb-2-2
Thanks!

It also occurs to me that having the RC tag in the POM is not
necessarily a problem.

So long as the tag is retained after a successful vote, then does it
matter whether the tag in the POM is IO-1.2.3-RC4 or IO-1.2.3 ?

On 15 April 2016 at 16:02, Brent Worden <[hidden email]> wrote:

> I probably won't be much help either as I have never used the plugin but,
> there is a tag option for the plugin that might help control the SCM tag
> that is used.  Of all the options for the plugin listed on
> https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html,
> the tag* options might meet your needs.
>
>
> Thanks,
>
> Brent
>
> On Fri, Apr 15, 2016 at 5:16 AM, Benson Margulies <[hidden email]>
> wrote:
>
>> On Thu, Apr 14, 2016 at 10:33 PM, sebb <[hidden email]> wrote:
>> > On 15 April 2016 at 02:19, Benson Margulies <[hidden email]>
>> wrote:
>> >> Sebb,
>> >>
>> >> I don't know why you think I could distinguish the following possible
>> >> behaviors of prior RMs with a reasonable level of effort:
>> >
>> > As I have already said, I don't use the plugin.
>> > However I have followed release votes and AFAICR the final tag never
>> > been created before the vote completed.
>> > In all cases I can remember, the final tag is created once the vote
>> > has completed.
>> > And I am pretty certain other RMs have used the release plugin.
>> >
>> > So it seems clear to me that something has gone wrong here.
>> >
>> > I don't know what, so I think we need input from an RM who has used
>> > the release plugin.
>> > They should be able to point out what is missing from the instructions.
>>
>> This started when I sent email two days ago saying that I was
>> perplexed by the instructions. I only proceeded when no prior RM, or
>> anyone else, answered.
>>
>> Maybe they used -DdryRun=true and then edited. Maybe I'm just being
>> obtuse. We'll see.
>>
>>
>>
>> >
>> >> 1: didn't use the maven-release-plugin
>> >> 2: did use the maven-release-plugin and then used svn mvn to rename
>> >> the tag it created
>> >> 3: did use the maven-release-plugin, typed 'commons-io-2.x-RCy' at the
>> >> prompt, and released with a pom with an incorrect scm element.
>> >> 4: something else I didn't think of.
>> >>
>> >> I didn't volunteer to be an archaeologist, I volunteered to be a
>> >> release manager..
>> >>
>> >> At best, the doc is, as I wrote to start this conversation,
>> >> incomplete, in that it does not give specific instructions for
>> >> achieving the PMC's goals using the plugin.
>> >>
>> >> To me, the following sequence is inoffensive:
>> >>
>> >> 1: run release:prepare, creating a premature 'real' tag.
>> >> 2: svn mv to convert that tag to an -RC tag.
>> >> 3: svn mv again to convert it to a (conventionally) immutable 'real
>> >> tag' if the vote passes.
>> >>
>> >> However, what I find inoffensive isn't important here. I'm not a PMC
>> >> member here. If this PMC has a strong policy of tag immutability, then
>> >> this PMC needs to document a procedure that both treats tags as
>> >> immutable and creates completely correct poms, including the scm
>> >> element that has to anticipate the eventual tag. It could create that
>> >> policy by erasing any mention of release:prepare, or by filling in the
>> >> missing details (though I continue to believe that there is no way to
>> >> make it come out the way you want.)
>> >>
>> >> Believe me, if I ever RM another commons release, I won't use
>> >> release:prepare until and unless someone writes up a step-by-step
>> >> guide that leads me to do so in an acceptable way.
>> >>
>> >> If you examine the 'tags' directory in svn right now, you will see
>> >> that it contains what I believe that you want it to contain: no
>> >> commons-io-2.5 tag, but rather a commons-io-2.5-RC4 tag. So, I
>> >> respectfully submit that we could proceed to decide if this release is
>> >> good enough, and sort out the documentation later.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
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?

Benson Margulies
On Fri, Apr 15, 2016 at 11:29 AM, sebb <[hidden email]> wrote:
> Thanks!
>
> It also occurs to me that having the RC tag in the POM is not
> necessarily a problem.


If you prefer to modify the doc to tell people how to use the plugin
so that the net result is the RC tag in the POM, OK. That satisfies my
ask for a set of instructions that an RM can follow without getting
into a controversy.

All this will be moot if some other voters don't show up.




>
> So long as the tag is retained after a successful vote, then does it
> matter whether the tag in the POM is IO-1.2.3-RC4 or IO-1.2.3 ?
>
> On 15 April 2016 at 16:02, Brent Worden <[hidden email]> wrote:
>> I probably won't be much help either as I have never used the plugin but,
>> there is a tag option for the plugin that might help control the SCM tag
>> that is used.  Of all the options for the plugin listed on
>> https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html,
>> the tag* options might meet your needs.
>>
>>
>> Thanks,
>>
>> Brent
>>
>> On Fri, Apr 15, 2016 at 5:16 AM, Benson Margulies <[hidden email]>
>> wrote:
>>
>>> On Thu, Apr 14, 2016 at 10:33 PM, sebb <[hidden email]> wrote:
>>> > On 15 April 2016 at 02:19, Benson Margulies <[hidden email]>
>>> wrote:
>>> >> Sebb,
>>> >>
>>> >> I don't know why you think I could distinguish the following possible
>>> >> behaviors of prior RMs with a reasonable level of effort:
>>> >
>>> > As I have already said, I don't use the plugin.
>>> > However I have followed release votes and AFAICR the final tag never
>>> > been created before the vote completed.
>>> > In all cases I can remember, the final tag is created once the vote
>>> > has completed.
>>> > And I am pretty certain other RMs have used the release plugin.
>>> >
>>> > So it seems clear to me that something has gone wrong here.
>>> >
>>> > I don't know what, so I think we need input from an RM who has used
>>> > the release plugin.
>>> > They should be able to point out what is missing from the instructions.
>>>
>>> This started when I sent email two days ago saying that I was
>>> perplexed by the instructions. I only proceeded when no prior RM, or
>>> anyone else, answered.
>>>
>>> Maybe they used -DdryRun=true and then edited. Maybe I'm just being
>>> obtuse. We'll see.
>>>
>>>
>>>
>>> >
>>> >> 1: didn't use the maven-release-plugin
>>> >> 2: did use the maven-release-plugin and then used svn mvn to rename
>>> >> the tag it created
>>> >> 3: did use the maven-release-plugin, typed 'commons-io-2.x-RCy' at the
>>> >> prompt, and released with a pom with an incorrect scm element.
>>> >> 4: something else I didn't think of.
>>> >>
>>> >> I didn't volunteer to be an archaeologist, I volunteered to be a
>>> >> release manager..
>>> >>
>>> >> At best, the doc is, as I wrote to start this conversation,
>>> >> incomplete, in that it does not give specific instructions for
>>> >> achieving the PMC's goals using the plugin.
>>> >>
>>> >> To me, the following sequence is inoffensive:
>>> >>
>>> >> 1: run release:prepare, creating a premature 'real' tag.
>>> >> 2: svn mv to convert that tag to an -RC tag.
>>> >> 3: svn mv again to convert it to a (conventionally) immutable 'real
>>> >> tag' if the vote passes.
>>> >>
>>> >> However, what I find inoffensive isn't important here. I'm not a PMC
>>> >> member here. If this PMC has a strong policy of tag immutability, then
>>> >> this PMC needs to document a procedure that both treats tags as
>>> >> immutable and creates completely correct poms, including the scm
>>> >> element that has to anticipate the eventual tag. It could create that
>>> >> policy by erasing any mention of release:prepare, or by filling in the
>>> >> missing details (though I continue to believe that there is no way to
>>> >> make it come out the way you want.)
>>> >>
>>> >> Believe me, if I ever RM another commons release, I won't use
>>> >> release:prepare until and unless someone writes up a step-by-step
>>> >> guide that leads me to do so in an acceptable way.
>>> >>
>>> >> If you examine the 'tags' directory in svn right now, you will see
>>> >> that it contains what I believe that you want it to contain: no
>>> >> commons-io-2.5 tag, but rather a commons-io-2.5-RC4 tag. So, I
>>> >> respectfully submit that we could proceed to decide if this release is
>>> >> good enough, and sort out the documentation later.
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: [hidden email]
>>> >> For additional commands, e-mail: [hidden email]
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [hidden email]
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
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
What is with everyone's aversion to using the Maven Release Plugin?  I
realize that it may not do exactly what we need out of the box, but it's a
very useful tool.  At home, I push a button in my Jenkins setup and it cuts
a new release to the Nexus OSS staging repository awaiting me to finalize
it.  Can we not do a process like that?  Perhaps we just create our own
variant of the release plugin in commons to do our release process?

On Fri, Apr 15, 2016 at 11:33 AM Benson Margulies <[hidden email]>
wrote:

> On Fri, Apr 15, 2016 at 11:29 AM, sebb <[hidden email]> wrote:
> > Thanks!
> >
> > It also occurs to me that having the RC tag in the POM is not
> > necessarily a problem.
>
>
> If you prefer to modify the doc to tell people how to use the plugin
> so that the net result is the RC tag in the POM, OK. That satisfies my
> ask for a set of instructions that an RM can follow without getting
> into a controversy.
>
> All this will be moot if some other voters don't show up.
>
>
>
>
> >
> > So long as the tag is retained after a successful vote, then does it
> > matter whether the tag in the POM is IO-1.2.3-RC4 or IO-1.2.3 ?
> >
> > On 15 April 2016 at 16:02, Brent Worden <[hidden email]> wrote:
> >> I probably won't be much help either as I have never used the plugin
> but,
> >> there is a tag option for the plugin that might help control the SCM tag
> >> that is used.  Of all the options for the plugin listed on
> >>
> https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
> ,
> >> the tag* options might meet your needs.
> >>
> >>
> >> Thanks,
> >>
> >> Brent
> >>
> >> On Fri, Apr 15, 2016 at 5:16 AM, Benson Margulies <
> [hidden email]>
> >> wrote:
> >>
> >>> On Thu, Apr 14, 2016 at 10:33 PM, sebb <[hidden email]> wrote:
> >>> > On 15 April 2016 at 02:19, Benson Margulies <[hidden email]>
> >>> wrote:
> >>> >> Sebb,
> >>> >>
> >>> >> I don't know why you think I could distinguish the following
> possible
> >>> >> behaviors of prior RMs with a reasonable level of effort:
> >>> >
> >>> > As I have already said, I don't use the plugin.
> >>> > However I have followed release votes and AFAICR the final tag never
> >>> > been created before the vote completed.
> >>> > In all cases I can remember, the final tag is created once the vote
> >>> > has completed.
> >>> > And I am pretty certain other RMs have used the release plugin.
> >>> >
> >>> > So it seems clear to me that something has gone wrong here.
> >>> >
> >>> > I don't know what, so I think we need input from an RM who has used
> >>> > the release plugin.
> >>> > They should be able to point out what is missing from the
> instructions.
> >>>
> >>> This started when I sent email two days ago saying that I was
> >>> perplexed by the instructions. I only proceeded when no prior RM, or
> >>> anyone else, answered.
> >>>
> >>> Maybe they used -DdryRun=true and then edited. Maybe I'm just being
> >>> obtuse. We'll see.
> >>>
> >>>
> >>>
> >>> >
> >>> >> 1: didn't use the maven-release-plugin
> >>> >> 2: did use the maven-release-plugin and then used svn mvn to rename
> >>> >> the tag it created
> >>> >> 3: did use the maven-release-plugin, typed 'commons-io-2.x-RCy' at
> the
> >>> >> prompt, and released with a pom with an incorrect scm element.
> >>> >> 4: something else I didn't think of.
> >>> >>
> >>> >> I didn't volunteer to be an archaeologist, I volunteered to be a
> >>> >> release manager..
> >>> >>
> >>> >> At best, the doc is, as I wrote to start this conversation,
> >>> >> incomplete, in that it does not give specific instructions for
> >>> >> achieving the PMC's goals using the plugin.
> >>> >>
> >>> >> To me, the following sequence is inoffensive:
> >>> >>
> >>> >> 1: run release:prepare, creating a premature 'real' tag.
> >>> >> 2: svn mv to convert that tag to an -RC tag.
> >>> >> 3: svn mv again to convert it to a (conventionally) immutable 'real
> >>> >> tag' if the vote passes.
> >>> >>
> >>> >> However, what I find inoffensive isn't important here. I'm not a PMC
> >>> >> member here. If this PMC has a strong policy of tag immutability,
> then
> >>> >> this PMC needs to document a procedure that both treats tags as
> >>> >> immutable and creates completely correct poms, including the scm
> >>> >> element that has to anticipate the eventual tag. It could create
> that
> >>> >> policy by erasing any mention of release:prepare, or by filling in
> the
> >>> >> missing details (though I continue to believe that there is no way
> to
> >>> >> make it come out the way you want.)
> >>> >>
> >>> >> Believe me, if I ever RM another commons release, I won't use
> >>> >> release:prepare until and unless someone writes up a step-by-step
> >>> >> guide that leads me to do so in an acceptable way.
> >>> >>
> >>> >> If you examine the 'tags' directory in svn right now, you will see
> >>> >> that it contains what I believe that you want it to contain: no
> >>> >> commons-io-2.5 tag, but rather a commons-io-2.5-RC4 tag. So, I
> >>> >> respectfully submit that we could proceed to decide if this release
> is
> >>> >> good enough, and sort out the documentation later.
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: [hidden email]
> >>> >> For additional commands, e-mail: [hidden email]
> >>> >>
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: [hidden email]
> >>> > For additional commands, e-mail: [hidden email]
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> 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?

Benson Margulies
On Fri, Apr 15, 2016 at 11:39 AM, James Carman
<[hidden email]> wrote:
> What is with everyone's aversion to using the Maven Release Plugin?  I
> realize that it may not do exactly what we need out of the box, but it's a
> very useful tool.  At home, I push a button in my Jenkins setup and it cuts
> a new release to the Nexus OSS staging repository awaiting me to finalize
> it.  Can we not do a process like that?  Perhaps we just create our own
> variant of the release plugin in commons to do our release process?
>

The maven-release-plugin is designed for a workflow which does not
match up with this PMC's policies.

The plugin's workflow is as follows:

1) edit the POM to contain the release version.
2) check that in.
3) make an SCM tag named after the release version.
4) edit the POM to the next snapshot.
5) check that in.


The problem is that this PMC does not want a tag named after the real
(not RC) version to come into existence  until after the vote passes.

However, the vote has to result from testing of the one and only
source archive that makes up the one and only legal release. So the
pom in there has to have its final form before the vote.

POMs contain, in effect, two versions: the <version/> element, and the
SCM tag. Some of us prefer them to be consistent. Sebb proposes to
escape this dilemma by allowing them to be inconsistent:
<version>2.5</version> while the SCM tag says 2.5-RC4, which will,
after all, point to the same revision/commit.

That's the reason for all the email.

---------------------------------------------------------------------
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
Actually Benson, you can specify the tag name to use when you run the release plugin.  release:prepare has a tag parameter.

Ralph

> On Apr 15, 2016, at 8:50 AM, Benson Margulies <[hidden email]> wrote:
>
> On Fri, Apr 15, 2016 at 11:39 AM, James Carman
> <[hidden email]> wrote:
>> What is with everyone's aversion to using the Maven Release Plugin?  I
>> realize that it may not do exactly what we need out of the box, but it's a
>> very useful tool.  At home, I push a button in my Jenkins setup and it cuts
>> a new release to the Nexus OSS staging repository awaiting me to finalize
>> it.  Can we not do a process like that?  Perhaps we just create our own
>> variant of the release plugin in commons to do our release process?
>>
>
> The maven-release-plugin is designed for a workflow which does not
> match up with this PMC's policies.
>
> The plugin's workflow is as follows:
>
> 1) edit the POM to contain the release version.
> 2) check that in.
> 3) make an SCM tag named after the release version.
> 4) edit the POM to the next snapshot.
> 5) check that in.
>
>
> The problem is that this PMC does not want a tag named after the real
> (not RC) version to come into existence  until after the vote passes.
>
> However, the vote has to result from testing of the one and only
> source archive that makes up the one and only legal release. So the
> pom in there has to have its final form before the vote.
>
> POMs contain, in effect, two versions: the <version/> element, and the
> SCM tag. Some of us prefer them to be consistent. Sebb proposes to
> escape this dilemma by allowing them to be inconsistent:
> <version>2.5</version> while the SCM tag says 2.5-RC4, which will,
> after all, point to the same revision/commit.
>
> That's the reason for all the email.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
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?

Benson Margulies
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.


>
> Ralph
>
>> On Apr 15, 2016, at 8:50 AM, Benson Margulies <[hidden email]> wrote:
>>
>> On Fri, Apr 15, 2016 at 11:39 AM, James Carman
>> <[hidden email]> wrote:
>>> What is with everyone's aversion to using the Maven Release Plugin?  I
>>> realize that it may not do exactly what we need out of the box, but it's a
>>> very useful tool.  At home, I push a button in my Jenkins setup and it cuts
>>> a new release to the Nexus OSS staging repository awaiting me to finalize
>>> it.  Can we not do a process like that?  Perhaps we just create our own
>>> variant of the release plugin in commons to do our release process?
>>>
>>
>> The maven-release-plugin is designed for a workflow which does not
>> match up with this PMC's policies.
>>
>> The plugin's workflow is as follows:
>>
>> 1) edit the POM to contain the release version.
>> 2) check that in.
>> 3) make an SCM tag named after the release version.
>> 4) edit the POM to the next snapshot.
>> 5) check that in.
>>
>>
>> The problem is that this PMC does not want a tag named after the real
>> (not RC) version to come into existence  until after the vote passes.
>>
>> However, the vote has to result from testing of the one and only
>> source archive that makes up the one and only legal release. So the
>> pom in there has to have its final form before the vote.
>>
>> POMs contain, in effect, two versions: the <version/> element, and the
>> SCM tag. Some of us prefer them to be consistent. Sebb proposes to
>> escape this dilemma by allowing them to be inconsistent:
>> <version>2.5</version> while the SCM tag says 2.5-RC4, which will,
>> after all, point to the same revision/commit.
>>
>> That's the reason for all the email.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
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?

sebb-2-2
In reply to this post by Benson Margulies
On 15 April 2016 at 16:50, Benson Margulies <[hidden email]> wrote:

> On Fri, Apr 15, 2016 at 11:39 AM, James Carman
> <[hidden email]> wrote:
>> What is with everyone's aversion to using the Maven Release Plugin?  I
>> realize that it may not do exactly what we need out of the box, but it's a
>> very useful tool.  At home, I push a button in my Jenkins setup and it cuts
>> a new release to the Nexus OSS staging repository awaiting me to finalize
>> it.  Can we not do a process like that?  Perhaps we just create our own
>> variant of the release plugin in commons to do our release process?
>>
>
> The maven-release-plugin is designed for a workflow which does not
> match up with this PMC's policies.
>
> The plugin's workflow is as follows:
>
> 1) edit the POM to contain the release version.
> 2) check that in.
> 3) make an SCM tag named after the release version.
> 4) edit the POM to the next snapshot.
> 5) check that in.
>
>
> The problem is that this PMC does not want a tag named after the real
> (not RC) version to come into existence  until after the vote passes.
>
> However, the vote has to result from testing of the one and only
> source archive that makes up the one and only legal release. So the
> pom in there has to have its final form before the vote.
>
> POMs contain, in effect, two versions: the <version/> element, and the
> SCM tag. Some of us prefer them to be consistent. Sebb proposes to
> escape this dilemma by allowing them to be inconsistent:
> <version>2.5</version> while the SCM tag says 2.5-RC4, which will,
> after all, point to the same revision/commit.
>
> That's the reason for all the email.

Note that Git rel/ tags *are* now immutable (unless Infra get
involved) so this is not a theoretical issue any more.

So it's important that the process is such that final tags are created
once and then left alone.


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

---------------------------------------------------------------------
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
In reply to this post by Benson Margulies
On Fri, Apr 15, 2016 at 11:50 AM Benson Margulies <[hidden email]>
wrote:

>
> The problem is that this PMC does not want a tag named after the real
> (not RC) version to come into existence  until after the vote passes.
>
>
Well, that's the thing that is somewhat silly.   The fact that there's a
"tag" doesn't (or shouldn't) mean something has been "released" by our
PMC.  With the setup I use, I log into Nexus OSS and basically approve the
staging repository so that it can be officially released.  So, we could
create a staging repository for folks to vote (along with the corresponding
tag).  If the vote fails, we just drop the staging repo.  Now, we could at
that point decide that we want to remove the tag and fix the version
numbers in the pom.xml files so that we can try again.  Or, we could just
use the next version number.  I don't really care one way or another.  We
could even call out releases specifically by copying the tag to
"releases/foo-1.2.3" or something.
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:38 PM James Carman <[hidden email]>
wrote:

> On Fri, Apr 15, 2016 at 11:50 AM Benson Margulies <[hidden email]>
> wrote:
>
>>
>> The problem is that this PMC does not want a tag named after the real
>> (not RC) version to come into existence  until after the vote passes.
>>
>>
> Well, that's the thing that is somewhat silly.   The fact that there's a
> "tag" doesn't (or shouldn't) mean something has been "released" by our
> PMC.  With the setup I use, I log into Nexus OSS and basically approve the
> staging repository so that it can be officially released.  So, we could
> create a staging repository for folks to vote (along with the corresponding
> tag).  If the vote fails, we just drop the staging repo.  Now, we could at
> that point decide that we want to remove the tag and fix the version
> numbers in the pom.xml files so that we can try again.  Or, we could just
> use the next version number.  I don't really care one way or another.  We
> could even call out releases specifically by copying the tag to
> "releases/foo-1.2.3" or something.
>

You can refer to our main page on releases here at the ASF:

http://www.apache.org/dev/release-publishing.html

which links to the maven-specific steps here:

http://www.apache.org/dev/publishing-maven-artifacts.html

This outlines a process very similar to what I described above (with the
exception that we're possibly using Git and not Subversion, but the
concepts are the same).
Reply | Threaded
Open this post in threaded view
|

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

sebb-2-2
In reply to this post by James Carman
On 15 April 2016 at 17:38, James Carman <[hidden email]> wrote:
> On Fri, Apr 15, 2016 at 11:50 AM Benson Margulies <[hidden email]>
> wrote:
>
>>
>> The problem is that this PMC does not want a tag named after the real
>> (not RC) version to come into existence  until after the vote passes.
>>
>>
> Well, that's the thing that is somewhat silly.

Not sure I follow why it is silly.

> The fact that there's a
> "tag" doesn't (or shouldn't) mean something has been "released" by our
> PMC.

This much is true, but the convention has always been to create the
final tag to correspond to the approved source revision.
And further, that such tags are immutable (which is now effectively
true for Git).
Therefore the tag can only be created once the release has been approved.

> With the setup I use, I log into Nexus OSS and basically approve the
> staging repository so that it can be officially released.  So, we could
> create a staging repository for folks to vote (along with the corresponding
> tag).  If the vote fails, we just drop the staging repo.  Now, we could at
> that point decide that we want to remove the tag and fix the version

Removing the tag is not possible for Git final tags.

> numbers in the pom.xml files so that we can try again.  Or, we could just
> use the next version number.

I think that is what Tomcat does.

> I don't really care one way or another.  We
> could even call out releases specifically by copying the tag to
> "releases/foo-1.2.3" or something.

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.

---------------------------------------------------------------------
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 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.
12