[VOTE] Should we respin CANCELLED releases with the same version number?

[Stephen Connolly <st...@gmail.com>]

We have been using a policy of only making releases without skipping
version numbers, e.g.

3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc

Whereby if there is something wrong with the artifacts staged for release,
we drop the staging repo, delete the tag, roll back the version, and run
again.

This vote is to change the policy to:

drop the staging repo, document the release as not released, and run with
the next version.

Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the
release criteria, then the artifacts would be dropped from the staging
repository and never see the light of day. The tag would remain in SCM, and
we would document (somewhere) that the release was cancelled. The "respin"
would have version number 3.1.1 and there would never be a 3.1.0.

This change could mean that the first actual release of 3.1.x might end up
being 3.1.67 (though I personally view that as unlikely, and in the context
of 3.1.x I think we are very nearly there)

Please Note:
http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
not actually specify what it means by "the process will need to be
restarted" so this vote will effect a change either outcome

+1: Never respin with the same version number, always increment the version
for a respin
0: Don't care
-1: Always respin with the same version number until that version number
gets released

This vote will be open for 72 hours. A Majority of PMC votes greater that 3
will be deemed as decisive in either direction (i.e. if the sum is < -3 or
> +3 then there is a documented result)

For any releases in progress at this point in time, it is up to the release
manager to decide what to do if they need to do a respin.

-Stephen

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Arnaud Héritier <ah...@gmail.com>]

+1 if it helps to have more regular releases (but I'm not sure it will help)


On Wed, May 29, 2013 at 1:10 PM, Gary Gregory <ga...@gmail.com>wrote:

> FWIW, over in Apache Commons land this is how we handle things.
>
> When we prepare and tag a release for version x.y.z, it is tagged as
> .../x.y.z-RC1. If the [vote] passes, the tag is copied to .../x.y.z. If the
> [vote] fails, the tag stays as a record of what happened and the email
> archives tell the story of why the vote failed. The next attempt is tagged
> as
> .../x.y.z-RC2, and so on.
>
> Some of this is detailed here
> https://wiki.apache.org/commons/UsingNexusand here
> https://commons.apache.org/releases/prepare.html
>
> Gary
>
>
> On Wed, May 29, 2013 at 6:01 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > We have been using a policy of only making releases without skipping
> > version numbers, e.g.
> >
> > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> >
> > Whereby if there is something wrong with the artifacts staged for
> release,
> > we drop the staging repo, delete the tag, roll back the version, and run
> > again.
> >
> > This vote is to change the policy to:
> >
> > drop the staging repo, document the release as not released, and run with
> > the next version.
> >
> > Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
> the
> > release criteria, then the artifacts would be dropped from the staging
> > repository and never see the light of day. The tag would remain in SCM,
> and
> > we would document (somewhere) that the release was cancelled. The
> "respin"
> > would have version number 3.1.1 and there would never be a 3.1.0.
> >
> > This change could mean that the first actual release of 3.1.x might end
> up
> > being 3.1.67 (though I personally view that as unlikely, and in the
> context
> > of 3.1.x I think we are very nearly there)
> >
> > Please Note:
> >
> >
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
> > not actually specify what it means by "the process will need to be
> > restarted" so this vote will effect a change either outcome
> >
> > +1: Never respin with the same version number, always increment the
> version
> > for a respin
> > 0: Don't care
> > -1: Always respin with the same version number until that version number
> > gets released
> >
> > This vote will be open for 72 hours. A Majority of PMC votes greater
> that 3
> > will be deemed as decisive in either direction (i.e. if the sum is < -3
> or
> > > +3 then there is a documented result)
> >
> > For any releases in progress at this point in time, it is up to the
> release
> > manager to decide what to do if they need to do a respin.
> >
> > -Stephen
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
>



-- 
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Gary Gregory <ga...@gmail.com>]

FWIW, over in Apache Commons land this is how we handle things.

When we prepare and tag a release for version x.y.z, it is tagged as
.../x.y.z-RC1. If the [vote] passes, the tag is copied to .../x.y.z. If the
[vote] fails, the tag stays as a record of what happened and the email
archives tell the story of why the vote failed. The next attempt is tagged
as
.../x.y.z-RC2, and so on.

Some of this is detailed here
https://wiki.apache.org/commons/UsingNexusand here
https://commons.apache.org/releases/prepare.html

Gary


On Wed, May 29, 2013 at 6:01 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> We have been using a policy of only making releases without skipping
> version numbers, e.g.
>
> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>
> Whereby if there is something wrong with the artifacts staged for release,
> we drop the staging repo, delete the tag, roll back the version, and run
> again.
>
> This vote is to change the policy to:
>
> drop the staging repo, document the release as not released, and run with
> the next version.
>
> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the
> release criteria, then the artifacts would be dropped from the staging
> repository and never see the light of day. The tag would remain in SCM, and
> we would document (somewhere) that the release was cancelled. The "respin"
> would have version number 3.1.1 and there would never be a 3.1.0.
>
> This change could mean that the first actual release of 3.1.x might end up
> being 3.1.67 (though I personally view that as unlikely, and in the context
> of 3.1.x I think we are very nearly there)
>
> Please Note:
>
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
> not actually specify what it means by "the process will need to be
> restarted" so this vote will effect a change either outcome
>
> +1: Never respin with the same version number, always increment the version
> for a respin
> 0: Don't care
> -1: Always respin with the same version number until that version number
> gets released
>
> This vote will be open for 72 hours. A Majority of PMC votes greater that 3
> will be deemed as decisive in either direction (i.e. if the sum is < -3 or
> > +3 then there is a documented result)
>
> For any releases in progress at this point in time, it is up to the release
> manager to decide what to do if they need to do a respin.
>
> -Stephen
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Chris Graham <ch...@gmail.com>]

Um, did I miss something, but what is a unreleased (ie for it to be pulled,
then it has to be right?) artifact doing in central to start with?

-Chris


On Tue, Jun 4, 2013 at 3:32 AM, Robert Scholte <rf...@apache.org> wrote:

> All nice ideas, but let's go back to a real usecase:
>
> Let's assume we're having an issue with componentX-1.4
> If you weren't one of the testers, then this dependency was pulled from
> Maven Central. You can check out the code as specified in the tag, etc.
> etc. No issues here.
> But if you were one of the testers you must be sure that you're not using
> the staged version anymore, but the one from Maven Central. When reusing
> version numbers due to unsuccessful staged versions, you can only confirm
> it by comparing the *revisions* of both componentX-1.4
> I think somehow (the rootcause of) MNG-5181 is related: if you're using an
> artifact originally from a staging repo and that repo has disappeared, the
> build must fail. You are forced to clean up these staged artifacts, so they
> are pulled from Maven Central. Only this way your local build is the same
> as any other developers build.
> As said before: - the actual release is the one in the dist-folder
> - tags are just an easy way to refer to a certain revision.
> - so if you want to be 100% sure you're checking out the correct source,
> use revisions and not tags (which means revision must be set during
> packaging, e.g in the manifest file).
>
> Robert
>
> Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies <
> bimargulies@gmail.com>:
>
>
>  I would consider it delux if the release plugin were enhanced to
>> support a more sophisticated mapping between artifact versions and
>> tags -- as per Kristian, wouldn't it be cool if it could iterate over
>> tags while repeating itself on customer-visible release numbers? I'd
>> help to code this is we had a collective understanding of how we
>> wanted it to work.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Robert Scholte <rf...@apache.org>]

Although it is slightly off-topic (I assumed our Apache environment), but  
also in this case: as long as componentX-1.4 was staged and not released,  
developers must adjust their settings.xml to test componentX-1.4.
So they should be aware that this component was not released and should  
remove it afterwards (when the release is dropped(?)).
So how important is tracking down if Maven could verify that your version  
of the componentX-1.4 is not the same as the released componentX-1.4? In  
such case keeping your version is useless, because your build will always  
be different then the one created by other developers.
IIUC even though we say "final version are only downloaded once", Maven3  
keeps verifying it with the original repository.

A worst case scenario would be if the build-server pulls in staged  
artifacts (because someone specified the staging URL and committed a  
pom.xml with this artifact as dependency) and the repository is used by  
all jobs. This might lead to false-positive test results or false-negative  
test-results.

When you're using a repository-manager without staging support, then the  
story is a bit different. In that case artifacts immediately end up in the  
company-repository and you'll loose track of who is using is. In such  
cases you should never redeploy with the same version.

Robert

Op Mon, 03 Jun 2013 19:49:19 +0200 schreef Stephen Connolly  
<st...@gmail.com>:

> Now the issue with componentX-1.4 that you wan to test is one that only
> shows up behind your corporate proxy, and you have a system set up with  
> the
> failing case and you dare not change anything...
>
> So you add the staging repo to your mirror, run the test case, and drop  
> the
> test artifact from the mirror as fast as you can... (Because creating a
> separate mirror would require changing the test setup and resulting in
> re-resolution again)
>
> The thing is that the test is a long test... And now you don't know who
> else has got that invalid componentX-1.4 (because your test is still
> failing) and when the fixed componentX-1.4 is released you may find a
> nightmare tracking it down again.
>
> Somewhat contrived some might say, but that is the use case where this s
> more critical
>
> On Monday, 3 June 2013, Robert Scholte wrote:
>
>> All nice ideas, but let's go back to a real usecase:
>>
>> Let's assume we're having an issue with componentX-1.4
>> If you weren't one of the testers, then this dependency was pulled from
>> Maven Central. You can check out the code as specified in the tag, etc.
>> etc. No issues here.
>> But if you were one of the testers you must be sure that you're not  
>> using
>> the staged version anymore, but the one from Maven Central. When reusing
>> version numbers due to unsuccessful staged versions, you can only  
>> confirm
>> it by comparing the *revisions* of both componentX-1.4
>> I think somehow (the rootcause of) MNG-5181 is related: if you're using  
>> an
>> artifact originally from a staging repo and that repo has disappeared,  
>> the
>> build must fail. You are forced to clean up these staged artifacts, so  
>> they
>> are pulled from Maven Central. Only this way your local build is the  
>> same
>> as any other developers build.
>> As said before: - the actual release is the one in the dist-folder
>> - tags are just an easy way to refer to a certain revision.
>> - so if you want to be 100% sure you're checking out the correct source,
>> use revisions and not tags (which means revision must be set during
>> packaging, e.g in the manifest file).
>>
>> Robert
>>
>> Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies <
>> bimargulies@gmail.com>:
>>
>>  I would consider it delux if the release plugin were enhanced to
>>> support a more sophisticated mapping between artifact versions and
>>> tags -- as per Kristian, wouldn't it be cool if it could iterate over
>>> tags while repeating itself on customer-visible release numbers? I'd
>>> help to code this is we had a collective understanding of how we
>>> wanted it to work.
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Barrie Treloar <ba...@gmail.com>]

Write this scenario up in the "trouble shooting" notes on how to test
staging releases.

I fit into the "behind corporate proxy" category but I have not had
this problem (I use Kristian's solution).
Admittedly the effort required to configure the corporate proxy for a
staging url is often enough to disuade me from testing that plugin.
It is easier to pull out my personal laptop and tether it to test the
plugin.

Anyway with this discussion captured somewhere, if it truly becomes an
issues for enough people they can find what we discussed and re-raise
options.

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Stephen Connolly <st...@gmail.com>]

On Monday, 3 June 2013, Kristian Rosenvold wrote:

> If you add apache staging to your corp proxy
> and expose that to everyone you are mixing test and production.
> /me dislikes the concept.
>
> The way I usually solve this is to have an additional
> corp repo-url that exposes the regular internal repo
> *and*  staging. This url is used to test staging.


The *point* is what happens when your test case machine is pointing to the
proxy. If you switch that to a different URL _maven.repositories will kick
in and re-resolve potentially breaking your test case.

The only way I can see out of such is to edit the test machine's hosts file
so that the DNs name gets resolved to a different server and that assumes
the proxy is referenced by DNS and not eg https:/
10.0.0.5/nexus/groups/public/

I did say this is likely a rare case, but it is the case that would force
burning version numbers, and the exception tests (or proves in old English)
the rule

(Anyway vote is over, so issue is moot. I don't care enough to call a
second vote)

> (I have yet to come across a scenaro where multiple
> users share this ;)
>
> Kristian
>
>
> 2013/6/3 Stephen Connolly <stephen.alan.connolly@gmail.com <javascript:;>
> >:
> > Now the issue with componentX-1.4 that you wan to test is one that only
> > shows up behind your corporate proxy, and you have a system set up with
> the
> > failing case and you dare not change anything...
> >
> > So you add the staging repo to your mirror, run the test case, and drop
> the
> > test artifact from the mirror as fast as you can... (Because creating a
> > separate mirror would require changing the test setup and resulting in
> > re-resolution again)
> >
> > The thing is that the test is a long test... And now you don't know who
> > else has got that invalid componentX-1.4 (because your test is still
> > failing) and when the fixed componentX-1.4 is released you may find a
> > nightmare tracking it down again.
> >
> > Somewhat contrived some might say, but that is the use case where this s
> > more critical
> >
> > On Monday, 3 June 2013, Robert Scholte wrote:
> >
> >> All nice ideas, but let's go back to a real usecase:
> >>
> >> Let's assume we're having an issue with componentX-1.4
> >> If you weren't one of the testers, then this dependency was pulled from
> >> Maven Central. You can check out the code as specified in the tag, etc.
> >> etc. No issues here.
> >> But if you were one of the testers you must be sure that you're not
> using
> >> the staged version anymore, but the one from Maven Central. When reusing
> >> version numbers due to unsuccessful staged versions, you can only
> confirm
> >> it by comparing the *revisions* of both componentX-1.4
> >> I think somehow (the rootcause of) MNG-5181 is related: if you're using
> an
> >> artifact originally from a staging repo and that repo has disappeared,
> the
> >> build must fail. You are forced to clean up these staged artifacts, so
> they
> >> are pulled from Maven Central. Only this way your local build is the
> same
> >> as any other developers build.
> >> As said before: - the actual release is the one in the dist-folder
> >> - tags are just an easy way to refer to a certain revision.
> >> - so if you want to be 100% sure you're checking out the correct source,
> >> use revisions and not tags (which means revision must be set during
> >> packaging, e.g in the manifest file).
> >>
> >> Robert
> >>
> >> Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies <
> >> bimargulies@gmail.com <javascript:;>>:
> >>
> >>  I would consider it delux if the release plugin were enhanced to
> >>> support a more sophisticated mapping between artifact versions and
> >>> tags -- as per Kristian, wouldn't it be cool if it could iterate over
> >>> tags while repeating itself on customer-visible release numbers? I'd
> >>> help to code this is we had a collective understanding of how we
> >>> wanted it to work.
> >>>
> >>>
> ------------------------------**------------------------------**---------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
> >>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >>>
> >>
> >>
> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> >> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >>
> >>
> >
> > --
> > Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Kristian Rosenvold <kr...@gmail.com>]

If you add apache staging to your corp proxy
and expose that to everyone you are mixing test and production.
/me dislikes the concept.

The way I usually solve this is to have an additional
corp repo-url that exposes the regular internal repo
*and*  staging. This url is used to test staging.
(I have yet to come across a scenaro where multiple
users share this ;)

Kristian


2013/6/3 Stephen Connolly <st...@gmail.com>:
> Now the issue with componentX-1.4 that you wan to test is one that only
> shows up behind your corporate proxy, and you have a system set up with the
> failing case and you dare not change anything...
>
> So you add the staging repo to your mirror, run the test case, and drop the
> test artifact from the mirror as fast as you can... (Because creating a
> separate mirror would require changing the test setup and resulting in
> re-resolution again)
>
> The thing is that the test is a long test... And now you don't know who
> else has got that invalid componentX-1.4 (because your test is still
> failing) and when the fixed componentX-1.4 is released you may find a
> nightmare tracking it down again.
>
> Somewhat contrived some might say, but that is the use case where this s
> more critical
>
> On Monday, 3 June 2013, Robert Scholte wrote:
>
>> All nice ideas, but let's go back to a real usecase:
>>
>> Let's assume we're having an issue with componentX-1.4
>> If you weren't one of the testers, then this dependency was pulled from
>> Maven Central. You can check out the code as specified in the tag, etc.
>> etc. No issues here.
>> But if you were one of the testers you must be sure that you're not using
>> the staged version anymore, but the one from Maven Central. When reusing
>> version numbers due to unsuccessful staged versions, you can only confirm
>> it by comparing the *revisions* of both componentX-1.4
>> I think somehow (the rootcause of) MNG-5181 is related: if you're using an
>> artifact originally from a staging repo and that repo has disappeared, the
>> build must fail. You are forced to clean up these staged artifacts, so they
>> are pulled from Maven Central. Only this way your local build is the same
>> as any other developers build.
>> As said before: - the actual release is the one in the dist-folder
>> - tags are just an easy way to refer to a certain revision.
>> - so if you want to be 100% sure you're checking out the correct source,
>> use revisions and not tags (which means revision must be set during
>> packaging, e.g in the manifest file).
>>
>> Robert
>>
>> Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies <
>> bimargulies@gmail.com>:
>>
>>  I would consider it delux if the release plugin were enhanced to
>>> support a more sophisticated mapping between artifact versions and
>>> tags -- as per Kristian, wouldn't it be cool if it could iterate over
>>> tags while repeating itself on customer-visible release numbers? I'd
>>> help to code this is we had a collective understanding of how we
>>> wanted it to work.
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> --
> Sent from my phone

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Stephen Connolly <st...@gmail.com>]

Now the issue with componentX-1.4 that you wan to test is one that only
shows up behind your corporate proxy, and you have a system set up with the
failing case and you dare not change anything...

So you add the staging repo to your mirror, run the test case, and drop the
test artifact from the mirror as fast as you can... (Because creating a
separate mirror would require changing the test setup and resulting in
re-resolution again)

The thing is that the test is a long test... And now you don't know who
else has got that invalid componentX-1.4 (because your test is still
failing) and when the fixed componentX-1.4 is released you may find a
nightmare tracking it down again.

Somewhat contrived some might say, but that is the use case where this s
more critical

On Monday, 3 June 2013, Robert Scholte wrote:

> All nice ideas, but let's go back to a real usecase:
>
> Let's assume we're having an issue with componentX-1.4
> If you weren't one of the testers, then this dependency was pulled from
> Maven Central. You can check out the code as specified in the tag, etc.
> etc. No issues here.
> But if you were one of the testers you must be sure that you're not using
> the staged version anymore, but the one from Maven Central. When reusing
> version numbers due to unsuccessful staged versions, you can only confirm
> it by comparing the *revisions* of both componentX-1.4
> I think somehow (the rootcause of) MNG-5181 is related: if you're using an
> artifact originally from a staging repo and that repo has disappeared, the
> build must fail. You are forced to clean up these staged artifacts, so they
> are pulled from Maven Central. Only this way your local build is the same
> as any other developers build.
> As said before: - the actual release is the one in the dist-folder
> - tags are just an easy way to refer to a certain revision.
> - so if you want to be 100% sure you're checking out the correct source,
> use revisions and not tags (which means revision must be set during
> packaging, e.g in the manifest file).
>
> Robert
>
> Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies <
> bimargulies@gmail.com>:
>
>  I would consider it delux if the release plugin were enhanced to
>> support a more sophisticated mapping between artifact versions and
>> tags -- as per Kristian, wouldn't it be cool if it could iterate over
>> tags while repeating itself on customer-visible release numbers? I'd
>> help to code this is we had a collective understanding of how we
>> wanted it to work.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

-- 
Sent from my phone

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Robert Scholte <rf...@apache.org>]

All nice ideas, but let's go back to a real usecase:

Let's assume we're having an issue with componentX-1.4
If you weren't one of the testers, then this dependency was pulled from  
Maven Central. You can check out the code as specified in the tag, etc.  
etc. No issues here.
But if you were one of the testers you must be sure that you're not using  
the staged version anymore, but the one from Maven Central. When reusing  
version numbers due to unsuccessful staged versions, you can only confirm  
it by comparing the *revisions* of both componentX-1.4
I think somehow (the rootcause of) MNG-5181 is related: if you're using an  
artifact originally from a staging repo and that repo has disappeared, the  
build must fail. You are forced to clean up these staged artifacts, so  
they are pulled from Maven Central. Only this way your local build is the  
same as any other developers build.
As said before: - the actual release is the one in the dist-folder
- tags are just an easy way to refer to a certain revision.
- so if you want to be 100% sure you're checking out the correct source,  
use revisions and not tags (which means revision must be set during  
packaging, e.g in the manifest file).

Robert

Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies  
<bi...@gmail.com>:

> I would consider it delux if the release plugin were enhanced to
> support a more sophisticated mapping between artifact versions and
> tags -- as per Kristian, wouldn't it be cool if it could iterate over
> tags while repeating itself on customer-visible release numbers? I'd
> help to code this is we had a collective understanding of how we
> wanted it to work.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Benson Margulies <bi...@gmail.com>]

I would consider it delux if the release plugin were enhanced to
support a more sophisticated mapping between artifact versions and
tags -- as per Kristian, wouldn't it be cool if it could iterate over
tags while repeating itself on customer-visible release numbers? I'd
help to code this is we had a collective understanding of how we
wanted it to work.

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Kristian Rosenvold <kr...@gmail.com>]

I think it's time to step back a little. This whole vote was started
without any proper initial discussion, so to the extent there will be
any majority for a policy change, this will not be the vote where this
happens. But these votes tend to be great kickstarters for good
discussions, so instead of getting all focused on voting
technicalities I'd simply like to point out the following:

A) There is a clear majority to not burn version numbers in maven central.
B) The relationship between an SCM tag and a maven central version number
     is really a weak link. The artifact "foobar" versioned "2.2" in
maven central could very well
     point to the scm tag foobar-2.2-take-29. The pom in central could
actually have
     this tag etched in. So in this case we did 28 previous SCM tags
that all contained the
     same maven version number.
C) In essence, we do not really care about what the SCM tag is, as
long as there is a well established convention for tagging. If one
desires a "proper" foobar-2.2 tag this can always be made once the
final artifact is approved (although for immutability reasons, the pom
in central would point at take-29).
D) We have a clear need to identify versions for the *process* of
releasing, which means
vote threads need clear markings of "take17", which may also
correspond to a "take17" tag. But the release target is still "2.2".
(Or, as in the case of maven core, a widely available alpha release
for general consumption for the brave). These tags are used to
organize our *process*.

So I basically think this is the wrong vote we're having. Hence my -1
on this procedural issue.

Kristian

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Stephen Connolly <st...@gmail.com>]

I will point out that for this specific vote I listed three options and a
criteria. So this vote has no vetoes. Simple sum of all binding votes
defines the result. If the sum is < -3 then that says majority dont want to
burn version numbers. If the sum > +3 then that says the majority want to
keep release version number labels as immutable and therefore burn version
numbers with each cancelled vote.

After 72h the total, by my count was -3 and has only gone further in that
direction. I think the reuse of version numbers has one this vote. If Hervé
wants to call a second vote for burning qualified version labels, fine by
me but my view is do for all releases the same

On Sunday, 2 June 2013, Fred Cooke wrote:

> I apologise. I had three tabs open from Apache, and grabbed the wrong one.
>
> According to the correct, page, though:
>
> -0.9: 'I *really* don't like this, but *I'm not going to stand in the
> way*if everyone else wants to go ahead with it.'
>
> There's an *implication* there that an extra -0.1 might change that to I
> *am
> * going to stand in the way. There's also a disclaimer in the intro that
> says "might be interpreted" and a "TBS" (To Be Specified?) in the
> procedures section.
>
> I believe I've seen Mojo release votes (not code mod votes) vetoed, and
> they (we? ugh) claim to use the same rules. Correct me if I'm wrong
> (again).
>
> So, Apache elders, what IS the procedure voting ruleset, and who's going to
> update that page so that it's clear?
>
> Fred.
>
> On Sun, Jun 2, 2013 at 9:11 PM, Benson Margulies <bimargulies@gmail.com<javascript:;>
> >wrote:
>
> > Thanks, Baptiste, that's the reference I was looking for.
> >
> >
> > On Sun, Jun 2, 2013 at 3:08 PM, Baptiste MATHUS <bm...@batmat.net>
> > wrote:
> > > That link is for HTTPd.
> > > For Apache general guidelines, read
> > > http://www.apache.org/foundation/voting.html
> > > -1 are only vetos for "code modification", not "procedural" issues .
> > >
> > > Cheers
> > >
> > >
> > > 2013/6/2 Fred Cooke <fr...@gmail.com>
> > >
> > >> Benson, read the rules:
> > >>
> > >> http://httpd.apache.org/dev/voting.html
> > >>
> > >> "*-1 *No, I *veto* this action."
> > >>
> > >> +1 + -1 != 0
> > >>
> > >> On Sun, Jun 2, 2013 at 8:55 PM, Benson Margulies <
> bimargulies@gmail.com
> > >> >wrote:
> > >>
> > >> > On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke <fr...@gmail.com>
> > wrote:
> > >> > >> from my experience, even if this question is not absolutely
> > >> > scm-specific,
> > >> > >> git
> > >> > >> brings us a new problem we didn't have with svn: once a tag is
> set
> > on
> > >> > the
> > >> > >> canonical repo and replicated on developers' repos, it is not
> > >> > automatically
> > >> > >> updated if updated in the canonical
> > >> > >>
> > >> > >
> > >> > > Git brings you no such "problem", it simply exposes your extremely
> > poor
> > >> > > practices... A tag should, and in any sane place is, permanent and
> > >> > > irrevocable.
> > >> > >
> > >> > > On another note, the veto by -1 vote mechanism is a great idea
> for a
> > >> > > release, but a terrible idea for a principle like this. For a
> > release
> > >> it
> > >> > > requires a justification, for this it's just "my opinion"
> overriding
> > >> one
> > >> > of
> > >> > > Maven's core principals.
> > >> >
> > >> >
> > >> > Fred,
> > >> >
> > >> > Who says that anyone has a veto? As a principle of Apache, very few
> > >> > things are subject to veto, and I can't see how this would be one.
> If
> > >> > there's a clear majority of opinion in favor of burning versions,
> > >> > we'll start burning versions. I voted -1. I'll live with whatever
> > >> > outcome, but I'd live more happily with a more elaborated
> description
> > >> > of the resulting procedure. Like, where and how do we document these
> > >> > never-born releases, etc, etc.
> > >> >
> > >> > --benson
> > >> >
> > >> >
> > >> > >
> > >> > > Stagnation wins.
> > >> > >
> > >> > > Fred.
> > >> > >
> > >> > >
> > >> > >>
> > >> > >> but I may miss some git-fu once again...
> > >> > >>
> > >> > >> Regards,
> > >> > >>
> > >> > >> Hervé
> > >> > >>
> > >> > >> Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> > >> > >> > >but as I see, there seems to be a consensus around a 2-sided
> > rule:
> > >> > >> > >- don't reuse version number for pre-releases (RC, etc)
> > >> > >> > >- reuse version number for actual releases
> > >> > >> >
> > >> > >> > Not sure how I feel about that.
> > >> > >> >
> > >> > >> > alpha/beta/RCx etc, they are all still valid version nos, so I
> > think
> > >> > that
> > >> > >> > the no re-spin rule should still apply in the same manner.
> > >> > >> >
> > >



-- 
Sent from my phone

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Fred Cooke <fr...@gmail.com>]

I apologise. I had three tabs open from Apache, and grabbed the wrong one.

According to the correct, page, though:

-0.9: 'I *really* don't like this, but *I'm not going to stand in the
way*if everyone else wants to go ahead with it.'

There's an *implication* there that an extra -0.1 might change that to I *am
* going to stand in the way. There's also a disclaimer in the intro that
says "might be interpreted" and a "TBS" (To Be Specified?) in the
procedures section.

I believe I've seen Mojo release votes (not code mod votes) vetoed, and
they (we? ugh) claim to use the same rules. Correct me if I'm wrong (again).

So, Apache elders, what IS the procedure voting ruleset, and who's going to
update that page so that it's clear?

Fred.

On Sun, Jun 2, 2013 at 9:11 PM, Benson Margulies <bi...@gmail.com>wrote:

> Thanks, Baptiste, that's the reference I was looking for.
>
>
> On Sun, Jun 2, 2013 at 3:08 PM, Baptiste MATHUS <bm...@batmat.net>
> wrote:
> > That link is for HTTPd.
> > For Apache general guidelines, read
> > http://www.apache.org/foundation/voting.html
> > -1 are only vetos for "code modification", not "procedural" issues .
> >
> > Cheers
> >
> >
> > 2013/6/2 Fred Cooke <fr...@gmail.com>
> >
> >> Benson, read the rules:
> >>
> >> http://httpd.apache.org/dev/voting.html
> >>
> >> "*-1 *No, I *veto* this action."
> >>
> >> +1 + -1 != 0
> >>
> >> On Sun, Jun 2, 2013 at 8:55 PM, Benson Margulies <bimargulies@gmail.com
> >> >wrote:
> >>
> >> > On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke <fr...@gmail.com>
> wrote:
> >> > >> from my experience, even if this question is not absolutely
> >> > scm-specific,
> >> > >> git
> >> > >> brings us a new problem we didn't have with svn: once a tag is set
> on
> >> > the
> >> > >> canonical repo and replicated on developers' repos, it is not
> >> > automatically
> >> > >> updated if updated in the canonical
> >> > >>
> >> > >
> >> > > Git brings you no such "problem", it simply exposes your extremely
> poor
> >> > > practices... A tag should, and in any sane place is, permanent and
> >> > > irrevocable.
> >> > >
> >> > > On another note, the veto by -1 vote mechanism is a great idea for a
> >> > > release, but a terrible idea for a principle like this. For a
> release
> >> it
> >> > > requires a justification, for this it's just "my opinion" overriding
> >> one
> >> > of
> >> > > Maven's core principals.
> >> >
> >> >
> >> > Fred,
> >> >
> >> > Who says that anyone has a veto? As a principle of Apache, very few
> >> > things are subject to veto, and I can't see how this would be one. If
> >> > there's a clear majority of opinion in favor of burning versions,
> >> > we'll start burning versions. I voted -1. I'll live with whatever
> >> > outcome, but I'd live more happily with a more elaborated description
> >> > of the resulting procedure. Like, where and how do we document these
> >> > never-born releases, etc, etc.
> >> >
> >> > --benson
> >> >
> >> >
> >> > >
> >> > > Stagnation wins.
> >> > >
> >> > > Fred.
> >> > >
> >> > >
> >> > >>
> >> > >> but I may miss some git-fu once again...
> >> > >>
> >> > >> Regards,
> >> > >>
> >> > >> Hervé
> >> > >>
> >> > >> Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> >> > >> > >but as I see, there seems to be a consensus around a 2-sided
> rule:
> >> > >> > >- don't reuse version number for pre-releases (RC, etc)
> >> > >> > >- reuse version number for actual releases
> >> > >> >
> >> > >> > Not sure how I feel about that.
> >> > >> >
> >> > >> > alpha/beta/RCx etc, they are all still valid version nos, so I
> think
> >> > that
> >> > >> > the no re-spin rule should still apply in the same manner.
> >> > >> >
> >> > >> > -Chris
> >> > >> >
> >> > >> > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <
> >> herve.boutemy@free.fr>
> >> > >> wrote:
> >> > >> > > yes, the vote for one unique rule is clearly "-1"
> >> > >> > >
> >> > >> > > but as I see, there seems to be a consensus around a 2-sided
> rule:
> >> > >> > > - don't reuse version number for pre-releases (RC, etc)
> >> > >> > > - reuse version number for actual releases
> >> > >> > >
> >> > >> > > Regards,
> >> > >> > >
> >> > >> > > Hervé
> >> > >> > >
> >> > >> > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> >> > >> > > > I will need to recheck the tally, but I think the result is
> -3
> >> > >> > > >
> >> > >> > > > So looks like we will be reusing version numbers on respins
> >> > >> > > >
> >> > >> > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
> >> > >> > > > > We have been using a policy of only making releases without
> >> > >> skipping
> >> > >> > > > > version numbers, e.g.
> >> > >> > > > >
> >> > >> > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> >> > >> > > > >
> >> > >> > > > > Whereby if there is something wrong with the artifacts
> staged
> >> > for
> >> > >> > >
> >> > >> > > release,
> >> > >> > >
> >> > >> > > > > we drop the staging repo, delete the tag, roll back the
> >> version,
> >> > >> and
> >> > >> > >
> >> > >> > > run
> >> > >> > >
> >> > >> > > > > again.
> >> > >> > > > >
> >> > >> > > > > This vote is to change the policy to:
> >> > >> > > > >
> >> > >> > > > > drop the staging repo, document the release as not
> released,
> >> and
> >> > >> run
> >> > >> > >
> >> > >> > > with
> >> > >> > >
> >> > >> > > > > the next version.
> >> > >> > > > >
> >> > >> > > > > Under this new proposal, if the staged artifacts for 3.1.0
> >> fail
> >> > to
> >> > >> > > > > meet
> >> > >> > > > > the release criteria, then the artifacts would be dropped
> from
> >> > the
> >> > >> > >
> >> > >> > > staging
> >> > >> > >
> >> > >> > > > > repository and never see the light of day. The tag would
> >> remain
> >> > in
> >> > >> > > > > SCM,
> >> > >> > > > > and
> >> > >> > > > > we would document (somewhere) that the release was
> cancelled.
> >> > The
> >> > >> > >
> >> > >> > > "respin"
> >> > >> > >
> >> > >> > > > > would have version number 3.1.1 and there would never be a
> >> > 3.1.0.
> >> > >> > > > >
> >> > >> > > > > This change could mean that the first actual release of
> 3.1.x
> >> > might
> >> > >> > >
> >> > >> > > end up
> >> > >> > >
> >> > >> > > > > being 3.1.67 (though I personally view that as unlikely,
> and
> >> in
> >> > the
> >> > >> > > > > context
> >> > >> > > > > of 3.1.x I think we are very nearly there)
> >> > >> > >
> >> > >> > > > > Please Note:
> >> > >> > >
> >> > >>
> >> >
> >>
> http://maven.apache.org/developers/release/maven-project-release-procedure
> >> > >> > >
> >> > >> > > > > .html#Check_the_vote_resultsdoes not actually specify what
> it
> >> > >> means by
> >> > >> > > > > "the process will need to be restarted" so this vote will
> >> > effect a
> >> > >> > >
> >> > >> > > change
> >> > >> > >
> >> > >> > > > > either outcome
> >> > >> > > > >
> >> > >> > > > > +1: Never respin with the same version number, always
> >> increment
> >> > the
> >> > >> > > > > version for a respin
> >> > >> > > > > 0: Don't care
> >> > >> > > > > -1: Always respin with the same version number until that
> >> > version
> >> > >> > >
> >> > >> > > number
> >> > >> > >
> >> > >> > > > > gets released
> >> > >> > > > >
> >> > >> > > > > This vote will be open for 72 hours. A Majority of PMC
> votes
> >> > >> greater
> >> > >> > >
> >> > >> > > that
> >> > >> > >
> >> > >> > > > > 3 will be deemed as decisive in either direction (i.e. if
> the
> >> > sum
> >> > >> is <
> >> > >> > >
> >> > >> > > -3
> >> > >> > >
> >> > >> > > > > or > +3 then there is a documented result)
> >> > >> > > > >
> >> > >> > > > > For any releases in progress at this point in time, it is
> up
> >> to
> >> > the
> >> > >> > > > > release manager to decide what to do if they need to do a
> >> > respin.
> >> > >> > > > >
> >> > >> > > > > -Stephen
> >> > >>
> >> > >>
> ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > >> For additional commands, e-mail: dev-help@maven.apache.org
> >> > >>
> >> > >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Baptiste <Batmat> MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Benson Margulies <bi...@gmail.com>]

Thanks, Baptiste, that's the reference I was looking for.


On Sun, Jun 2, 2013 at 3:08 PM, Baptiste MATHUS <bm...@batmat.net> wrote:
> That link is for HTTPd.
> For Apache general guidelines, read
> http://www.apache.org/foundation/voting.html
> -1 are only vetos for "code modification", not "procedural" issues .
>
> Cheers
>
>
> 2013/6/2 Fred Cooke <fr...@gmail.com>
>
>> Benson, read the rules:
>>
>> http://httpd.apache.org/dev/voting.html
>>
>> "*-1 *No, I *veto* this action."
>>
>> +1 + -1 != 0
>>
>> On Sun, Jun 2, 2013 at 8:55 PM, Benson Margulies <bimargulies@gmail.com
>> >wrote:
>>
>> > On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke <fr...@gmail.com> wrote:
>> > >> from my experience, even if this question is not absolutely
>> > scm-specific,
>> > >> git
>> > >> brings us a new problem we didn't have with svn: once a tag is set on
>> > the
>> > >> canonical repo and replicated on developers' repos, it is not
>> > automatically
>> > >> updated if updated in the canonical
>> > >>
>> > >
>> > > Git brings you no such "problem", it simply exposes your extremely poor
>> > > practices... A tag should, and in any sane place is, permanent and
>> > > irrevocable.
>> > >
>> > > On another note, the veto by -1 vote mechanism is a great idea for a
>> > > release, but a terrible idea for a principle like this. For a release
>> it
>> > > requires a justification, for this it's just "my opinion" overriding
>> one
>> > of
>> > > Maven's core principals.
>> >
>> >
>> > Fred,
>> >
>> > Who says that anyone has a veto? As a principle of Apache, very few
>> > things are subject to veto, and I can't see how this would be one. If
>> > there's a clear majority of opinion in favor of burning versions,
>> > we'll start burning versions. I voted -1. I'll live with whatever
>> > outcome, but I'd live more happily with a more elaborated description
>> > of the resulting procedure. Like, where and how do we document these
>> > never-born releases, etc, etc.
>> >
>> > --benson
>> >
>> >
>> > >
>> > > Stagnation wins.
>> > >
>> > > Fred.
>> > >
>> > >
>> > >>
>> > >> but I may miss some git-fu once again...
>> > >>
>> > >> Regards,
>> > >>
>> > >> Hervé
>> > >>
>> > >> Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
>> > >> > >but as I see, there seems to be a consensus around a 2-sided rule:
>> > >> > >- don't reuse version number for pre-releases (RC, etc)
>> > >> > >- reuse version number for actual releases
>> > >> >
>> > >> > Not sure how I feel about that.
>> > >> >
>> > >> > alpha/beta/RCx etc, they are all still valid version nos, so I think
>> > that
>> > >> > the no re-spin rule should still apply in the same manner.
>> > >> >
>> > >> > -Chris
>> > >> >
>> > >> > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <
>> herve.boutemy@free.fr>
>> > >> wrote:
>> > >> > > yes, the vote for one unique rule is clearly "-1"
>> > >> > >
>> > >> > > but as I see, there seems to be a consensus around a 2-sided rule:
>> > >> > > - don't reuse version number for pre-releases (RC, etc)
>> > >> > > - reuse version number for actual releases
>> > >> > >
>> > >> > > Regards,
>> > >> > >
>> > >> > > Hervé
>> > >> > >
>> > >> > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
>> > >> > > > I will need to recheck the tally, but I think the result is -3
>> > >> > > >
>> > >> > > > So looks like we will be reusing version numbers on respins
>> > >> > > >
>> > >> > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
>> > >> > > > > We have been using a policy of only making releases without
>> > >> skipping
>> > >> > > > > version numbers, e.g.
>> > >> > > > >
>> > >> > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>> > >> > > > >
>> > >> > > > > Whereby if there is something wrong with the artifacts staged
>> > for
>> > >> > >
>> > >> > > release,
>> > >> > >
>> > >> > > > > we drop the staging repo, delete the tag, roll back the
>> version,
>> > >> and
>> > >> > >
>> > >> > > run
>> > >> > >
>> > >> > > > > again.
>> > >> > > > >
>> > >> > > > > This vote is to change the policy to:
>> > >> > > > >
>> > >> > > > > drop the staging repo, document the release as not released,
>> and
>> > >> run
>> > >> > >
>> > >> > > with
>> > >> > >
>> > >> > > > > the next version.
>> > >> > > > >
>> > >> > > > > Under this new proposal, if the staged artifacts for 3.1.0
>> fail
>> > to
>> > >> > > > > meet
>> > >> > > > > the release criteria, then the artifacts would be dropped from
>> > the
>> > >> > >
>> > >> > > staging
>> > >> > >
>> > >> > > > > repository and never see the light of day. The tag would
>> remain
>> > in
>> > >> > > > > SCM,
>> > >> > > > > and
>> > >> > > > > we would document (somewhere) that the release was cancelled.
>> > The
>> > >> > >
>> > >> > > "respin"
>> > >> > >
>> > >> > > > > would have version number 3.1.1 and there would never be a
>> > 3.1.0.
>> > >> > > > >
>> > >> > > > > This change could mean that the first actual release of 3.1.x
>> > might
>> > >> > >
>> > >> > > end up
>> > >> > >
>> > >> > > > > being 3.1.67 (though I personally view that as unlikely, and
>> in
>> > the
>> > >> > > > > context
>> > >> > > > > of 3.1.x I think we are very nearly there)
>> > >> > >
>> > >> > > > > Please Note:
>> > >> > >
>> > >>
>> >
>> http://maven.apache.org/developers/release/maven-project-release-procedure
>> > >> > >
>> > >> > > > > .html#Check_the_vote_resultsdoes not actually specify what it
>> > >> means by
>> > >> > > > > "the process will need to be restarted" so this vote will
>> > effect a
>> > >> > >
>> > >> > > change
>> > >> > >
>> > >> > > > > either outcome
>> > >> > > > >
>> > >> > > > > +1: Never respin with the same version number, always
>> increment
>> > the
>> > >> > > > > version for a respin
>> > >> > > > > 0: Don't care
>> > >> > > > > -1: Always respin with the same version number until that
>> > version
>> > >> > >
>> > >> > > number
>> > >> > >
>> > >> > > > > gets released
>> > >> > > > >
>> > >> > > > > This vote will be open for 72 hours. A Majority of PMC votes
>> > >> greater
>> > >> > >
>> > >> > > that
>> > >> > >
>> > >> > > > > 3 will be deemed as decisive in either direction (i.e. if the
>> > sum
>> > >> is <
>> > >> > >
>> > >> > > -3
>> > >> > >
>> > >> > > > > or > +3 then there is a documented result)
>> > >> > > > >
>> > >> > > > > For any releases in progress at this point in time, it is up
>> to
>> > the
>> > >> > > > > release manager to decide what to do if they need to do a
>> > respin.
>> > >> > > > >
>> > >> > > > > -Stephen
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> For additional commands, e-mail: dev-help@maven.apache.org
>> > >>
>> > >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>
>
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Baptiste MATHUS <bm...@batmat.net>]

That link is for HTTPd.
For Apache general guidelines, read
http://www.apache.org/foundation/voting.html
-1 are only vetos for "code modification", not "procedural" issues .

Cheers


2013/6/2 Fred Cooke <fr...@gmail.com>

> Benson, read the rules:
>
> http://httpd.apache.org/dev/voting.html
>
> "*-1 *No, I *veto* this action."
>
> +1 + -1 != 0
>
> On Sun, Jun 2, 2013 at 8:55 PM, Benson Margulies <bimargulies@gmail.com
> >wrote:
>
> > On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke <fr...@gmail.com> wrote:
> > >> from my experience, even if this question is not absolutely
> > scm-specific,
> > >> git
> > >> brings us a new problem we didn't have with svn: once a tag is set on
> > the
> > >> canonical repo and replicated on developers' repos, it is not
> > automatically
> > >> updated if updated in the canonical
> > >>
> > >
> > > Git brings you no such "problem", it simply exposes your extremely poor
> > > practices... A tag should, and in any sane place is, permanent and
> > > irrevocable.
> > >
> > > On another note, the veto by -1 vote mechanism is a great idea for a
> > > release, but a terrible idea for a principle like this. For a release
> it
> > > requires a justification, for this it's just "my opinion" overriding
> one
> > of
> > > Maven's core principals.
> >
> >
> > Fred,
> >
> > Who says that anyone has a veto? As a principle of Apache, very few
> > things are subject to veto, and I can't see how this would be one. If
> > there's a clear majority of opinion in favor of burning versions,
> > we'll start burning versions. I voted -1. I'll live with whatever
> > outcome, but I'd live more happily with a more elaborated description
> > of the resulting procedure. Like, where and how do we document these
> > never-born releases, etc, etc.
> >
> > --benson
> >
> >
> > >
> > > Stagnation wins.
> > >
> > > Fred.
> > >
> > >
> > >>
> > >> but I may miss some git-fu once again...
> > >>
> > >> Regards,
> > >>
> > >> Hervé
> > >>
> > >> Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> > >> > >but as I see, there seems to be a consensus around a 2-sided rule:
> > >> > >- don't reuse version number for pre-releases (RC, etc)
> > >> > >- reuse version number for actual releases
> > >> >
> > >> > Not sure how I feel about that.
> > >> >
> > >> > alpha/beta/RCx etc, they are all still valid version nos, so I think
> > that
> > >> > the no re-spin rule should still apply in the same manner.
> > >> >
> > >> > -Chris
> > >> >
> > >> > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <
> herve.boutemy@free.fr>
> > >> wrote:
> > >> > > yes, the vote for one unique rule is clearly "-1"
> > >> > >
> > >> > > but as I see, there seems to be a consensus around a 2-sided rule:
> > >> > > - don't reuse version number for pre-releases (RC, etc)
> > >> > > - reuse version number for actual releases
> > >> > >
> > >> > > Regards,
> > >> > >
> > >> > > Hervé
> > >> > >
> > >> > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> > >> > > > I will need to recheck the tally, but I think the result is -3
> > >> > > >
> > >> > > > So looks like we will be reusing version numbers on respins
> > >> > > >
> > >> > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
> > >> > > > > We have been using a policy of only making releases without
> > >> skipping
> > >> > > > > version numbers, e.g.
> > >> > > > >
> > >> > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > >> > > > >
> > >> > > > > Whereby if there is something wrong with the artifacts staged
> > for
> > >> > >
> > >> > > release,
> > >> > >
> > >> > > > > we drop the staging repo, delete the tag, roll back the
> version,
> > >> and
> > >> > >
> > >> > > run
> > >> > >
> > >> > > > > again.
> > >> > > > >
> > >> > > > > This vote is to change the policy to:
> > >> > > > >
> > >> > > > > drop the staging repo, document the release as not released,
> and
> > >> run
> > >> > >
> > >> > > with
> > >> > >
> > >> > > > > the next version.
> > >> > > > >
> > >> > > > > Under this new proposal, if the staged artifacts for 3.1.0
> fail
> > to
> > >> > > > > meet
> > >> > > > > the release criteria, then the artifacts would be dropped from
> > the
> > >> > >
> > >> > > staging
> > >> > >
> > >> > > > > repository and never see the light of day. The tag would
> remain
> > in
> > >> > > > > SCM,
> > >> > > > > and
> > >> > > > > we would document (somewhere) that the release was cancelled.
> > The
> > >> > >
> > >> > > "respin"
> > >> > >
> > >> > > > > would have version number 3.1.1 and there would never be a
> > 3.1.0.
> > >> > > > >
> > >> > > > > This change could mean that the first actual release of 3.1.x
> > might
> > >> > >
> > >> > > end up
> > >> > >
> > >> > > > > being 3.1.67 (though I personally view that as unlikely, and
> in
> > the
> > >> > > > > context
> > >> > > > > of 3.1.x I think we are very nearly there)
> > >> > >
> > >> > > > > Please Note:
> > >> > >
> > >>
> >
> http://maven.apache.org/developers/release/maven-project-release-procedure
> > >> > >
> > >> > > > > .html#Check_the_vote_resultsdoes not actually specify what it
> > >> means by
> > >> > > > > "the process will need to be restarted" so this vote will
> > effect a
> > >> > >
> > >> > > change
> > >> > >
> > >> > > > > either outcome
> > >> > > > >
> > >> > > > > +1: Never respin with the same version number, always
> increment
> > the
> > >> > > > > version for a respin
> > >> > > > > 0: Don't care
> > >> > > > > -1: Always respin with the same version number until that
> > version
> > >> > >
> > >> > > number
> > >> > >
> > >> > > > > gets released
> > >> > > > >
> > >> > > > > This vote will be open for 72 hours. A Majority of PMC votes
> > >> greater
> > >> > >
> > >> > > that
> > >> > >
> > >> > > > > 3 will be deemed as decisive in either direction (i.e. if the
> > sum
> > >> is <
> > >> > >
> > >> > > -3
> > >> > >
> > >> > > > > or > +3 then there is a documented result)
> > >> > > > >
> > >> > > > > For any releases in progress at this point in time, it is up
> to
> > the
> > >> > > > > release manager to decide what to do if they need to do a
> > respin.
> > >> > > > >
> > >> > > > > -Stephen
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>



-- 
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Benson Margulies <bi...@gmail.com>]

1. That page says 'obsolete' all over the top of it.

2. I can find you 27 email messages from board members and other
crusty veterans to the contrary.

Quoting from the replacement page:

-1 No. On issues where consensus is required, this vote counts as a
veto. All vetos must include an explanation of why the veto is
appropriate. A veto with no explanation is void. No veto can be
overruled. If you disagree with the veto, you should lobby the person
who cast the veto. Voters intending to veto an action item should make
their opinions known to the group immediately, so that the problem can
be remedied as early as possible.

Now, the next question to ask is this: On what issues is a consensus
_required_? That page lists a very narrow set of things. However,
since that page is specific to the Apache HTTPD community, it's not
binding on us, one way or another.

However, it's always good for a community to make decisions by
consensus in the general sense of the term. So, I ask my fellow -1
voters: who here thinks that by voting -1 they were irrevocably
blocking consensus? I didn't. As a PMC member, I'm very much opposed
to vetos on this sort of policy item; everyone should get a chance to
express their views, and everyone should feel heard, and then a
majority is good enough for me.




On Sun, Jun 2, 2013 at 3:02 PM, Fred Cooke <fr...@gmail.com> wrote:
> Benson, read the rules:
>
> http://httpd.apache.org/dev/voting.html
>
> "*-1 *No, I *veto* this action."
>
> +1 + -1 != 0
>
> On Sun, Jun 2, 2013 at 8:55 PM, Benson Margulies <bi...@gmail.com>wrote:
>
>> On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke <fr...@gmail.com> wrote:
>> >> from my experience, even if this question is not absolutely
>> scm-specific,
>> >> git
>> >> brings us a new problem we didn't have with svn: once a tag is set on
>> the
>> >> canonical repo and replicated on developers' repos, it is not
>> automatically
>> >> updated if updated in the canonical
>> >>
>> >
>> > Git brings you no such "problem", it simply exposes your extremely poor
>> > practices... A tag should, and in any sane place is, permanent and
>> > irrevocable.
>> >
>> > On another note, the veto by -1 vote mechanism is a great idea for a
>> > release, but a terrible idea for a principle like this. For a release it
>> > requires a justification, for this it's just "my opinion" overriding one
>> of
>> > Maven's core principals.
>>
>>
>> Fred,
>>
>> Who says that anyone has a veto? As a principle of Apache, very few
>> things are subject to veto, and I can't see how this would be one. If
>> there's a clear majority of opinion in favor of burning versions,
>> we'll start burning versions. I voted -1. I'll live with whatever
>> outcome, but I'd live more happily with a more elaborated description
>> of the resulting procedure. Like, where and how do we document these
>> never-born releases, etc, etc.
>>
>> --benson
>>
>>
>> >
>> > Stagnation wins.
>> >
>> > Fred.
>> >
>> >
>> >>
>> >> but I may miss some git-fu once again...
>> >>
>> >> Regards,
>> >>
>> >> Hervé
>> >>
>> >> Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
>> >> > >but as I see, there seems to be a consensus around a 2-sided rule:
>> >> > >- don't reuse version number for pre-releases (RC, etc)
>> >> > >- reuse version number for actual releases
>> >> >
>> >> > Not sure how I feel about that.
>> >> >
>> >> > alpha/beta/RCx etc, they are all still valid version nos, so I think
>> that
>> >> > the no re-spin rule should still apply in the same manner.
>> >> >
>> >> > -Chris
>> >> >
>> >> > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <he...@free.fr>
>> >> wrote:
>> >> > > yes, the vote for one unique rule is clearly "-1"
>> >> > >
>> >> > > but as I see, there seems to be a consensus around a 2-sided rule:
>> >> > > - don't reuse version number for pre-releases (RC, etc)
>> >> > > - reuse version number for actual releases
>> >> > >
>> >> > > Regards,
>> >> > >
>> >> > > Hervé
>> >> > >
>> >> > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
>> >> > > > I will need to recheck the tally, but I think the result is -3
>> >> > > >
>> >> > > > So looks like we will be reusing version numbers on respins
>> >> > > >
>> >> > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
>> >> > > > > We have been using a policy of only making releases without
>> >> skipping
>> >> > > > > version numbers, e.g.
>> >> > > > >
>> >> > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>> >> > > > >
>> >> > > > > Whereby if there is something wrong with the artifacts staged
>> for
>> >> > >
>> >> > > release,
>> >> > >
>> >> > > > > we drop the staging repo, delete the tag, roll back the version,
>> >> and
>> >> > >
>> >> > > run
>> >> > >
>> >> > > > > again.
>> >> > > > >
>> >> > > > > This vote is to change the policy to:
>> >> > > > >
>> >> > > > > drop the staging repo, document the release as not released, and
>> >> run
>> >> > >
>> >> > > with
>> >> > >
>> >> > > > > the next version.
>> >> > > > >
>> >> > > > > Under this new proposal, if the staged artifacts for 3.1.0 fail
>> to
>> >> > > > > meet
>> >> > > > > the release criteria, then the artifacts would be dropped from
>> the
>> >> > >
>> >> > > staging
>> >> > >
>> >> > > > > repository and never see the light of day. The tag would remain
>> in
>> >> > > > > SCM,
>> >> > > > > and
>> >> > > > > we would document (somewhere) that the release was cancelled.
>> The
>> >> > >
>> >> > > "respin"
>> >> > >
>> >> > > > > would have version number 3.1.1 and there would never be a
>> 3.1.0.
>> >> > > > >
>> >> > > > > This change could mean that the first actual release of 3.1.x
>> might
>> >> > >
>> >> > > end up
>> >> > >
>> >> > > > > being 3.1.67 (though I personally view that as unlikely, and in
>> the
>> >> > > > > context
>> >> > > > > of 3.1.x I think we are very nearly there)
>> >> > >
>> >> > > > > Please Note:
>> >> > >
>> >>
>> http://maven.apache.org/developers/release/maven-project-release-procedure
>> >> > >
>> >> > > > > .html#Check_the_vote_resultsdoes not actually specify what it
>> >> means by
>> >> > > > > "the process will need to be restarted" so this vote will
>> effect a
>> >> > >
>> >> > > change
>> >> > >
>> >> > > > > either outcome
>> >> > > > >
>> >> > > > > +1: Never respin with the same version number, always increment
>> the
>> >> > > > > version for a respin
>> >> > > > > 0: Don't care
>> >> > > > > -1: Always respin with the same version number until that
>> version
>> >> > >
>> >> > > number
>> >> > >
>> >> > > > > gets released
>> >> > > > >
>> >> > > > > This vote will be open for 72 hours. A Majority of PMC votes
>> >> greater
>> >> > >
>> >> > > that
>> >> > >
>> >> > > > > 3 will be deemed as decisive in either direction (i.e. if the
>> sum
>> >> is <
>> >> > >
>> >> > > -3
>> >> > >
>> >> > > > > or > +3 then there is a documented result)
>> >> > > > >
>> >> > > > > For any releases in progress at this point in time, it is up to
>> the
>> >> > > > > release manager to decide what to do if they need to do a
>> respin.
>> >> > > > >
>> >> > > > > -Stephen
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Fred Cooke <fr...@gmail.com>]

Benson, read the rules:

http://httpd.apache.org/dev/voting.html

"*-1 *No, I *veto* this action."

+1 + -1 != 0

On Sun, Jun 2, 2013 at 8:55 PM, Benson Margulies <bi...@gmail.com>wrote:

> On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke <fr...@gmail.com> wrote:
> >> from my experience, even if this question is not absolutely
> scm-specific,
> >> git
> >> brings us a new problem we didn't have with svn: once a tag is set on
> the
> >> canonical repo and replicated on developers' repos, it is not
> automatically
> >> updated if updated in the canonical
> >>
> >
> > Git brings you no such "problem", it simply exposes your extremely poor
> > practices... A tag should, and in any sane place is, permanent and
> > irrevocable.
> >
> > On another note, the veto by -1 vote mechanism is a great idea for a
> > release, but a terrible idea for a principle like this. For a release it
> > requires a justification, for this it's just "my opinion" overriding one
> of
> > Maven's core principals.
>
>
> Fred,
>
> Who says that anyone has a veto? As a principle of Apache, very few
> things are subject to veto, and I can't see how this would be one. If
> there's a clear majority of opinion in favor of burning versions,
> we'll start burning versions. I voted -1. I'll live with whatever
> outcome, but I'd live more happily with a more elaborated description
> of the resulting procedure. Like, where and how do we document these
> never-born releases, etc, etc.
>
> --benson
>
>
> >
> > Stagnation wins.
> >
> > Fred.
> >
> >
> >>
> >> but I may miss some git-fu once again...
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> >> > >but as I see, there seems to be a consensus around a 2-sided rule:
> >> > >- don't reuse version number for pre-releases (RC, etc)
> >> > >- reuse version number for actual releases
> >> >
> >> > Not sure how I feel about that.
> >> >
> >> > alpha/beta/RCx etc, they are all still valid version nos, so I think
> that
> >> > the no re-spin rule should still apply in the same manner.
> >> >
> >> > -Chris
> >> >
> >> > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <he...@free.fr>
> >> wrote:
> >> > > yes, the vote for one unique rule is clearly "-1"
> >> > >
> >> > > but as I see, there seems to be a consensus around a 2-sided rule:
> >> > > - don't reuse version number for pre-releases (RC, etc)
> >> > > - reuse version number for actual releases
> >> > >
> >> > > Regards,
> >> > >
> >> > > Hervé
> >> > >
> >> > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> >> > > > I will need to recheck the tally, but I think the result is -3
> >> > > >
> >> > > > So looks like we will be reusing version numbers on respins
> >> > > >
> >> > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
> >> > > > > We have been using a policy of only making releases without
> >> skipping
> >> > > > > version numbers, e.g.
> >> > > > >
> >> > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> >> > > > >
> >> > > > > Whereby if there is something wrong with the artifacts staged
> for
> >> > >
> >> > > release,
> >> > >
> >> > > > > we drop the staging repo, delete the tag, roll back the version,
> >> and
> >> > >
> >> > > run
> >> > >
> >> > > > > again.
> >> > > > >
> >> > > > > This vote is to change the policy to:
> >> > > > >
> >> > > > > drop the staging repo, document the release as not released, and
> >> run
> >> > >
> >> > > with
> >> > >
> >> > > > > the next version.
> >> > > > >
> >> > > > > Under this new proposal, if the staged artifacts for 3.1.0 fail
> to
> >> > > > > meet
> >> > > > > the release criteria, then the artifacts would be dropped from
> the
> >> > >
> >> > > staging
> >> > >
> >> > > > > repository and never see the light of day. The tag would remain
> in
> >> > > > > SCM,
> >> > > > > and
> >> > > > > we would document (somewhere) that the release was cancelled.
> The
> >> > >
> >> > > "respin"
> >> > >
> >> > > > > would have version number 3.1.1 and there would never be a
> 3.1.0.
> >> > > > >
> >> > > > > This change could mean that the first actual release of 3.1.x
> might
> >> > >
> >> > > end up
> >> > >
> >> > > > > being 3.1.67 (though I personally view that as unlikely, and in
> the
> >> > > > > context
> >> > > > > of 3.1.x I think we are very nearly there)
> >> > >
> >> > > > > Please Note:
> >> > >
> >>
> http://maven.apache.org/developers/release/maven-project-release-procedure
> >> > >
> >> > > > > .html#Check_the_vote_resultsdoes not actually specify what it
> >> means by
> >> > > > > "the process will need to be restarted" so this vote will
> effect a
> >> > >
> >> > > change
> >> > >
> >> > > > > either outcome
> >> > > > >
> >> > > > > +1: Never respin with the same version number, always increment
> the
> >> > > > > version for a respin
> >> > > > > 0: Don't care
> >> > > > > -1: Always respin with the same version number until that
> version
> >> > >
> >> > > number
> >> > >
> >> > > > > gets released
> >> > > > >
> >> > > > > This vote will be open for 72 hours. A Majority of PMC votes
> >> greater
> >> > >
> >> > > that
> >> > >
> >> > > > > 3 will be deemed as decisive in either direction (i.e. if the
> sum
> >> is <
> >> > >
> >> > > -3
> >> > >
> >> > > > > or > +3 then there is a documented result)
> >> > > > >
> >> > > > > For any releases in progress at this point in time, it is up to
> the
> >> > > > > release manager to decide what to do if they need to do a
> respin.
> >> > > > >
> >> > > > > -Stephen
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Benson Margulies <bi...@gmail.com>]

On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke <fr...@gmail.com> wrote:
>> from my experience, even if this question is not absolutely scm-specific,
>> git
>> brings us a new problem we didn't have with svn: once a tag is set on the
>> canonical repo and replicated on developers' repos, it is not automatically
>> updated if updated in the canonical
>>
>
> Git brings you no such "problem", it simply exposes your extremely poor
> practices... A tag should, and in any sane place is, permanent and
> irrevocable.
>
> On another note, the veto by -1 vote mechanism is a great idea for a
> release, but a terrible idea for a principle like this. For a release it
> requires a justification, for this it's just "my opinion" overriding one of
> Maven's core principals.


Fred,

Who says that anyone has a veto? As a principle of Apache, very few
things are subject to veto, and I can't see how this would be one. If
there's a clear majority of opinion in favor of burning versions,
we'll start burning versions. I voted -1. I'll live with whatever
outcome, but I'd live more happily with a more elaborated description
of the resulting procedure. Like, where and how do we document these
never-born releases, etc, etc.

--benson


>
> Stagnation wins.
>
> Fred.
>
>
>>
>> but I may miss some git-fu once again...
>>
>> Regards,
>>
>> Hervé
>>
>> Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
>> > >but as I see, there seems to be a consensus around a 2-sided rule:
>> > >- don't reuse version number for pre-releases (RC, etc)
>> > >- reuse version number for actual releases
>> >
>> > Not sure how I feel about that.
>> >
>> > alpha/beta/RCx etc, they are all still valid version nos, so I think that
>> > the no re-spin rule should still apply in the same manner.
>> >
>> > -Chris
>> >
>> > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <he...@free.fr>
>> wrote:
>> > > yes, the vote for one unique rule is clearly "-1"
>> > >
>> > > but as I see, there seems to be a consensus around a 2-sided rule:
>> > > - don't reuse version number for pre-releases (RC, etc)
>> > > - reuse version number for actual releases
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
>> > > > I will need to recheck the tally, but I think the result is -3
>> > > >
>> > > > So looks like we will be reusing version numbers on respins
>> > > >
>> > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
>> > > > > We have been using a policy of only making releases without
>> skipping
>> > > > > version numbers, e.g.
>> > > > >
>> > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>> > > > >
>> > > > > Whereby if there is something wrong with the artifacts staged for
>> > >
>> > > release,
>> > >
>> > > > > we drop the staging repo, delete the tag, roll back the version,
>> and
>> > >
>> > > run
>> > >
>> > > > > again.
>> > > > >
>> > > > > This vote is to change the policy to:
>> > > > >
>> > > > > drop the staging repo, document the release as not released, and
>> run
>> > >
>> > > with
>> > >
>> > > > > the next version.
>> > > > >
>> > > > > Under this new proposal, if the staged artifacts for 3.1.0 fail to
>> > > > > meet
>> > > > > the release criteria, then the artifacts would be dropped from the
>> > >
>> > > staging
>> > >
>> > > > > repository and never see the light of day. The tag would remain in
>> > > > > SCM,
>> > > > > and
>> > > > > we would document (somewhere) that the release was cancelled. The
>> > >
>> > > "respin"
>> > >
>> > > > > would have version number 3.1.1 and there would never be a 3.1.0.
>> > > > >
>> > > > > This change could mean that the first actual release of 3.1.x might
>> > >
>> > > end up
>> > >
>> > > > > being 3.1.67 (though I personally view that as unlikely, and in the
>> > > > > context
>> > > > > of 3.1.x I think we are very nearly there)
>> > >
>> > > > > Please Note:
>> > >
>> http://maven.apache.org/developers/release/maven-project-release-procedure
>> > >
>> > > > > .html#Check_the_vote_resultsdoes not actually specify what it
>> means by
>> > > > > "the process will need to be restarted" so this vote will effect a
>> > >
>> > > change
>> > >
>> > > > > either outcome
>> > > > >
>> > > > > +1: Never respin with the same version number, always increment the
>> > > > > version for a respin
>> > > > > 0: Don't care
>> > > > > -1: Always respin with the same version number until that version
>> > >
>> > > number
>> > >
>> > > > > gets released
>> > > > >
>> > > > > This vote will be open for 72 hours. A Majority of PMC votes
>> greater
>> > >
>> > > that
>> > >
>> > > > > 3 will be deemed as decisive in either direction (i.e. if the sum
>> is <
>> > >
>> > > -3
>> > >
>> > > > > or > +3 then there is a documented result)
>> > > > >
>> > > > > For any releases in progress at this point in time, it is up to the
>> > > > > release manager to decide what to do if they need to do a respin.
>> > > > >
>> > > > > -Stephen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Chris Graham <ch...@gmail.com>]

On Mon, Jun 3, 2013 at 10:52 AM, Benson Margulies <bi...@gmail.com>wrote:

> On Sun, Jun 2, 2013 at 8:44 PM, Fred Cooke <fr...@gmail.com> wrote:
> > Although I prefer to use Git, it's totally irrelevant. I'm unsure how you
> > came to the conclusion that I thought this was anything to do with Git.
> > Subversion tags, though mutable, should not EVER be committed against or
> in
> > any other way modified.
>
>
>  Doing so is the behaviour of a (bad quality) grad
> > student, not a software development professional!
>
> Fred,
>
> Do you realize that those are, ahem, 'fighting words'? That this
> development community, along with a slew of other Apache communities,
> have treated this as a good practice for years? The net effect is that
> you calling us all unprofessional idiots.
>
> We may eventually change over to your preferred methodology, but
> insulting us wholesale is not, in my opinion, a very effective way to
> move opinion in your direction.
>
> Our policy has been that we want the SVN/scm tag to be one-to-one with
> the voted source which is one-to-one with the Maven metadata. Deleting
> and creating tags is consistent with that policy so long as we don't
> modify them thereafter. And we don't.
>
>
Benson,

Nicely worded.

And thanks for pointing out the " so long as we don't modify them
thereafter. And we don't." bit.

That is the well understood process, one that I think is valuable (as we
all understand [and adhered too]).

-Chris

--benson
>
>
>
>
> >
> > On Mon, Jun 3, 2013 at 2:31 AM, Chris Graham <ch...@gmail.com>
> wrote:
> >
> >> Fred,
> >>
> >> We are talking more process here. Not the specifics of an individual
> SCM,
> >> not everything is in git. We are still talking about the abstraction api
> >> that the maven-scm handlers provide, of which git is but one.
> >>
> >> -Chris
> >>
> >>
> >> On Mon, Jun 3, 2013 at 4:42 AM, Fred Cooke <fr...@gmail.com>
> wrote:
> >>
> >> > > from my experience, even if this question is not absolutely
> >> scm-specific,
> >> > > git
> >> > > brings us a new problem we didn't have with svn: once a tag is set
> on
> >> the
> >> > > canonical repo and replicated on developers' repos, it is not
> >> > automatically
> >> > > updated if updated in the canonical
> >> > >
> >> >
> >> > Git brings you no such "problem", it simply exposes your extremely
> poor
> >> > practices... A tag should, and in any sane place is, permanent and
> >> > irrevocable.
> >> >
> >> > On another note, the veto by -1 vote mechanism is a great idea for a
> >> > release, but a terrible idea for a principle like this. For a release
> it
> >> > requires a justification, for this it's just "my opinion" overriding
> one
> >> of
> >> > Maven's core principals.
> >> >
> >> > Stagnation wins.
> >> >
> >> > Fred.
> >> >
> >> >
> >> > >
> >> > > but I may miss some git-fu once again...
> >> > >
> >> > > Regards,
> >> > >
> >> > > Hervé
> >> > >
> >> > > Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> >> > > > >but as I see, there seems to be a consensus around a 2-sided
> rule:
> >> > > > >- don't reuse version number for pre-releases (RC, etc)
> >> > > > >- reuse version number for actual releases
> >> > > >
> >> > > > Not sure how I feel about that.
> >> > > >
> >> > > > alpha/beta/RCx etc, they are all still valid version nos, so I
> think
> >> > that
> >> > > > the no re-spin rule should still apply in the same manner.
> >> > > >
> >> > > > -Chris
> >> > > >
> >> > > > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <
> herve.boutemy@free.fr
> >> >
> >> > > wrote:
> >> > > > > yes, the vote for one unique rule is clearly "-1"
> >> > > > >
> >> > > > > but as I see, there seems to be a consensus around a 2-sided
> rule:
> >> > > > > - don't reuse version number for pre-releases (RC, etc)
> >> > > > > - reuse version number for actual releases
> >> > > > >
> >> > > > > Regards,
> >> > > > >
> >> > > > > Hervé
> >> > > > >
> >> > > > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> >> > > > > > I will need to recheck the tally, but I think the result is -3
> >> > > > > >
> >> > > > > > So looks like we will be reusing version numbers on respins
> >> > > > > >
> >> > > > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
> >> > > > > > > We have been using a policy of only making releases without
> >> > > skipping
> >> > > > > > > version numbers, e.g.
> >> > > > > > >
> >> > > > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> >> > > > > > >
> >> > > > > > > Whereby if there is something wrong with the artifacts
> staged
> >> for
> >> > > > >
> >> > > > > release,
> >> > > > >
> >> > > > > > > we drop the staging repo, delete the tag, roll back the
> >> version,
> >> > > and
> >> > > > >
> >> > > > > run
> >> > > > >
> >> > > > > > > again.
> >> > > > > > >
> >> > > > > > > This vote is to change the policy to:
> >> > > > > > >
> >> > > > > > > drop the staging repo, document the release as not released,
> >> and
> >> > > run
> >> > > > >
> >> > > > > with
> >> > > > >
> >> > > > > > > the next version.
> >> > > > > > >
> >> > > > > > > Under this new proposal, if the staged artifacts for 3.1.0
> fail
> >> > to
> >> > > > > > > meet
> >> > > > > > > the release criteria, then the artifacts would be dropped
> from
> >> > the
> >> > > > >
> >> > > > > staging
> >> > > > >
> >> > > > > > > repository and never see the light of day. The tag would
> remain
> >> > in
> >> > > > > > > SCM,
> >> > > > > > > and
> >> > > > > > > we would document (somewhere) that the release was
> cancelled.
> >> The
> >> > > > >
> >> > > > > "respin"
> >> > > > >
> >> > > > > > > would have version number 3.1.1 and there would never be a
> >> 3.1.0.
> >> > > > > > >
> >> > > > > > > This change could mean that the first actual release of
> 3.1.x
> >> > might
> >> > > > >
> >> > > > > end up
> >> > > > >
> >> > > > > > > being 3.1.67 (though I personally view that as unlikely,
> and in
> >> > the
> >> > > > > > > context
> >> > > > > > > of 3.1.x I think we are very nearly there)
> >> > > > >
> >> > > > > > > Please Note:
> >> > > > >
> >> > >
> >> >
> >>
> http://maven.apache.org/developers/release/maven-project-release-procedure
> >> > > > >
> >> > > > > > > .html#Check_the_vote_resultsdoes not actually specify what
> it
> >> > > means by
> >> > > > > > > "the process will need to be restarted" so this vote will
> >> effect
> >> > a
> >> > > > >
> >> > > > > change
> >> > > > >
> >> > > > > > > either outcome
> >> > > > > > >
> >> > > > > > > +1: Never respin with the same version number, always
> increment
> >> > the
> >> > > > > > > version for a respin
> >> > > > > > > 0: Don't care
> >> > > > > > > -1: Always respin with the same version number until that
> >> version
> >> > > > >
> >> > > > > number
> >> > > > >
> >> > > > > > > gets released
> >> > > > > > >
> >> > > > > > > This vote will be open for 72 hours. A Majority of PMC votes
> >> > > greater
> >> > > > >
> >> > > > > that
> >> > > > >
> >> > > > > > > 3 will be deemed as decisive in either direction (i.e. if
> the
> >> sum
> >> > > is <
> >> > > > >
> >> > > > > -3
> >> > > > >
> >> > > > > > > or > +3 then there is a documented result)
> >> > > > > > >
> >> > > > > > > For any releases in progress at this point in time, it is
> up to
> >> > the
> >> > > > > > > release manager to decide what to do if they need to do a
> >> respin.
> >> > > > > > >
> >> > > > > > > -Stephen
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > >
> >> > >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Benson Margulies <bi...@gmail.com>]

On Sun, Jun 2, 2013 at 8:44 PM, Fred Cooke <fr...@gmail.com> wrote:
> Although I prefer to use Git, it's totally irrelevant. I'm unsure how you
> came to the conclusion that I thought this was anything to do with Git.
> Subversion tags, though mutable, should not EVER be committed against or in
> any other way modified.


 Doing so is the behaviour of a (bad quality) grad
> student, not a software development professional!

Fred,

Do you realize that those are, ahem, 'fighting words'? That this
development community, along with a slew of other Apache communities,
have treated this as a good practice for years? The net effect is that
you calling us all unprofessional idiots.

We may eventually change over to your preferred methodology, but
insulting us wholesale is not, in my opinion, a very effective way to
move opinion in your direction.

Our policy has been that we want the SVN/scm tag to be one-to-one with
the voted source which is one-to-one with the Maven metadata. Deleting
and creating tags is consistent with that policy so long as we don't
modify them thereafter. And we don't.

--benson




>
> On Mon, Jun 3, 2013 at 2:31 AM, Chris Graham <ch...@gmail.com> wrote:
>
>> Fred,
>>
>> We are talking more process here. Not the specifics of an individual SCM,
>> not everything is in git. We are still talking about the abstraction api
>> that the maven-scm handlers provide, of which git is but one.
>>
>> -Chris
>>
>>
>> On Mon, Jun 3, 2013 at 4:42 AM, Fred Cooke <fr...@gmail.com> wrote:
>>
>> > > from my experience, even if this question is not absolutely
>> scm-specific,
>> > > git
>> > > brings us a new problem we didn't have with svn: once a tag is set on
>> the
>> > > canonical repo and replicated on developers' repos, it is not
>> > automatically
>> > > updated if updated in the canonical
>> > >
>> >
>> > Git brings you no such "problem", it simply exposes your extremely poor
>> > practices... A tag should, and in any sane place is, permanent and
>> > irrevocable.
>> >
>> > On another note, the veto by -1 vote mechanism is a great idea for a
>> > release, but a terrible idea for a principle like this. For a release it
>> > requires a justification, for this it's just "my opinion" overriding one
>> of
>> > Maven's core principals.
>> >
>> > Stagnation wins.
>> >
>> > Fred.
>> >
>> >
>> > >
>> > > but I may miss some git-fu once again...
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
>> > > > >but as I see, there seems to be a consensus around a 2-sided rule:
>> > > > >- don't reuse version number for pre-releases (RC, etc)
>> > > > >- reuse version number for actual releases
>> > > >
>> > > > Not sure how I feel about that.
>> > > >
>> > > > alpha/beta/RCx etc, they are all still valid version nos, so I think
>> > that
>> > > > the no re-spin rule should still apply in the same manner.
>> > > >
>> > > > -Chris
>> > > >
>> > > > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <herve.boutemy@free.fr
>> >
>> > > wrote:
>> > > > > yes, the vote for one unique rule is clearly "-1"
>> > > > >
>> > > > > but as I see, there seems to be a consensus around a 2-sided rule:
>> > > > > - don't reuse version number for pre-releases (RC, etc)
>> > > > > - reuse version number for actual releases
>> > > > >
>> > > > > Regards,
>> > > > >
>> > > > > Hervé
>> > > > >
>> > > > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
>> > > > > > I will need to recheck the tally, but I think the result is -3
>> > > > > >
>> > > > > > So looks like we will be reusing version numbers on respins
>> > > > > >
>> > > > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
>> > > > > > > We have been using a policy of only making releases without
>> > > skipping
>> > > > > > > version numbers, e.g.
>> > > > > > >
>> > > > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>> > > > > > >
>> > > > > > > Whereby if there is something wrong with the artifacts staged
>> for
>> > > > >
>> > > > > release,
>> > > > >
>> > > > > > > we drop the staging repo, delete the tag, roll back the
>> version,
>> > > and
>> > > > >
>> > > > > run
>> > > > >
>> > > > > > > again.
>> > > > > > >
>> > > > > > > This vote is to change the policy to:
>> > > > > > >
>> > > > > > > drop the staging repo, document the release as not released,
>> and
>> > > run
>> > > > >
>> > > > > with
>> > > > >
>> > > > > > > the next version.
>> > > > > > >
>> > > > > > > Under this new proposal, if the staged artifacts for 3.1.0 fail
>> > to
>> > > > > > > meet
>> > > > > > > the release criteria, then the artifacts would be dropped from
>> > the
>> > > > >
>> > > > > staging
>> > > > >
>> > > > > > > repository and never see the light of day. The tag would remain
>> > in
>> > > > > > > SCM,
>> > > > > > > and
>> > > > > > > we would document (somewhere) that the release was cancelled.
>> The
>> > > > >
>> > > > > "respin"
>> > > > >
>> > > > > > > would have version number 3.1.1 and there would never be a
>> 3.1.0.
>> > > > > > >
>> > > > > > > This change could mean that the first actual release of 3.1.x
>> > might
>> > > > >
>> > > > > end up
>> > > > >
>> > > > > > > being 3.1.67 (though I personally view that as unlikely, and in
>> > the
>> > > > > > > context
>> > > > > > > of 3.1.x I think we are very nearly there)
>> > > > >
>> > > > > > > Please Note:
>> > > > >
>> > >
>> >
>> http://maven.apache.org/developers/release/maven-project-release-procedure
>> > > > >
>> > > > > > > .html#Check_the_vote_resultsdoes not actually specify what it
>> > > means by
>> > > > > > > "the process will need to be restarted" so this vote will
>> effect
>> > a
>> > > > >
>> > > > > change
>> > > > >
>> > > > > > > either outcome
>> > > > > > >
>> > > > > > > +1: Never respin with the same version number, always increment
>> > the
>> > > > > > > version for a respin
>> > > > > > > 0: Don't care
>> > > > > > > -1: Always respin with the same version number until that
>> version
>> > > > >
>> > > > > number
>> > > > >
>> > > > > > > gets released
>> > > > > > >
>> > > > > > > This vote will be open for 72 hours. A Majority of PMC votes
>> > > greater
>> > > > >
>> > > > > that
>> > > > >
>> > > > > > > 3 will be deemed as decisive in either direction (i.e. if the
>> sum
>> > > is <
>> > > > >
>> > > > > -3
>> > > > >
>> > > > > > > or > +3 then there is a documented result)
>> > > > > > >
>> > > > > > > For any releases in progress at this point in time, it is up to
>> > the
>> > > > > > > release manager to decide what to do if they need to do a
>> respin.
>> > > > > > >
>> > > > > > > -Stephen
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> >
>>

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Fred Cooke <fr...@gmail.com>]

Please stop addressing me. I'm done with this thread. The futility is
killing me. I've *MUCH* better things to do with my time. I'm 110% certain
that 101% of you will be pleased by this. Win win.

Fred.

On Mon, Jun 3, 2013 at 3:27 AM, Chris Graham <ch...@gmail.com> wrote:

> Fred, you're the one who mentioned git in that post.
>
> Please remember what stephen pointed out (which I thought was rather nicely
> worded): [paraphrased]
>
>                 The real release is the source bundle, and the tags are
> merely a convienance to a developer.
>
> -Chris
>
>
> On Mon, Jun 3, 2013 at 10:44 AM, Fred Cooke <fr...@gmail.com> wrote:
>
> > Although I prefer to use Git, it's totally irrelevant. I'm unsure how you
> > came to the conclusion that I thought this was anything to do with Git.
> > Subversion tags, though mutable, should not EVER be committed against or
> in
> > any other way modified. Doing so is the behaviour of a (bad quality) grad
> > student, not a software development professional!
> >
> > On Mon, Jun 3, 2013 at 2:31 AM, Chris Graham <ch...@gmail.com>
> wrote:
> >
> > > Fred,
> > >
> > > We are talking more process here. Not the specifics of an individual
> SCM,
> > > not everything is in git. We are still talking about the abstraction
> api
> > > that the maven-scm handlers provide, of which git is but one.
> > >
> > > -Chris
> > >
> > >
> > > On Mon, Jun 3, 2013 at 4:42 AM, Fred Cooke <fr...@gmail.com>
> wrote:
> > >
> > > > > from my experience, even if this question is not absolutely
> > > scm-specific,
> > > > > git
> > > > > brings us a new problem we didn't have with svn: once a tag is set
> on
> > > the
> > > > > canonical repo and replicated on developers' repos, it is not
> > > > automatically
> > > > > updated if updated in the canonical
> > > > >
> > > >
> > > > Git brings you no such "problem", it simply exposes your extremely
> poor
> > > > practices... A tag should, and in any sane place is, permanent and
> > > > irrevocable.
> > > >
> > > > On another note, the veto by -1 vote mechanism is a great idea for a
> > > > release, but a terrible idea for a principle like this. For a release
> > it
> > > > requires a justification, for this it's just "my opinion" overriding
> > one
> > > of
> > > > Maven's core principals.
> > > >
> > > > Stagnation wins.
> > > >
> > > > Fred.
> > > >
> > > >
> > > > >
> > > > > but I may miss some git-fu once again...
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> > > > > > >but as I see, there seems to be a consensus around a 2-sided
> rule:
> > > > > > >- don't reuse version number for pre-releases (RC, etc)
> > > > > > >- reuse version number for actual releases
> > > > > >
> > > > > > Not sure how I feel about that.
> > > > > >
> > > > > > alpha/beta/RCx etc, they are all still valid version nos, so I
> > think
> > > > that
> > > > > > the no re-spin rule should still apply in the same manner.
> > > > > >
> > > > > > -Chris
> > > > > >
> > > > > > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <
> > herve.boutemy@free.fr
> > > >
> > > > > wrote:
> > > > > > > yes, the vote for one unique rule is clearly "-1"
> > > > > > >
> > > > > > > but as I see, there seems to be a consensus around a 2-sided
> > rule:
> > > > > > > - don't reuse version number for pre-releases (RC, etc)
> > > > > > > - reuse version number for actual releases
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Hervé
> > > > > > >
> > > > > > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> > > > > > > > I will need to recheck the tally, but I think the result is
> -3
> > > > > > > >
> > > > > > > > So looks like we will be reusing version numbers on respins
> > > > > > > >
> > > > > > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
> > > > > > > > > We have been using a policy of only making releases without
> > > > > skipping
> > > > > > > > > version numbers, e.g.
> > > > > > > > >
> > > > > > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > > > > > > > >
> > > > > > > > > Whereby if there is something wrong with the artifacts
> staged
> > > for
> > > > > > >
> > > > > > > release,
> > > > > > >
> > > > > > > > > we drop the staging repo, delete the tag, roll back the
> > > version,
> > > > > and
> > > > > > >
> > > > > > > run
> > > > > > >
> > > > > > > > > again.
> > > > > > > > >
> > > > > > > > > This vote is to change the policy to:
> > > > > > > > >
> > > > > > > > > drop the staging repo, document the release as not
> released,
> > > and
> > > > > run
> > > > > > >
> > > > > > > with
> > > > > > >
> > > > > > > > > the next version.
> > > > > > > > >
> > > > > > > > > Under this new proposal, if the staged artifacts for 3.1.0
> > fail
> > > > to
> > > > > > > > > meet
> > > > > > > > > the release criteria, then the artifacts would be dropped
> > from
> > > > the
> > > > > > >
> > > > > > > staging
> > > > > > >
> > > > > > > > > repository and never see the light of day. The tag would
> > remain
> > > > in
> > > > > > > > > SCM,
> > > > > > > > > and
> > > > > > > > > we would document (somewhere) that the release was
> cancelled.
> > > The
> > > > > > >
> > > > > > > "respin"
> > > > > > >
> > > > > > > > > would have version number 3.1.1 and there would never be a
> > > 3.1.0.
> > > > > > > > >
> > > > > > > > > This change could mean that the first actual release of
> 3.1.x
> > > > might
> > > > > > >
> > > > > > > end up
> > > > > > >
> > > > > > > > > being 3.1.67 (though I personally view that as unlikely,
> and
> > in
> > > > the
> > > > > > > > > context
> > > > > > > > > of 3.1.x I think we are very nearly there)
> > > > > > >
> > > > > > > > > Please Note:
> > > > > > >
> > > > >
> > > >
> > >
> >
> http://maven.apache.org/developers/release/maven-project-release-procedure
> > > > > > >
> > > > > > > > > .html#Check_the_vote_resultsdoes not actually specify what
> it
> > > > > means by
> > > > > > > > > "the process will need to be restarted" so this vote will
> > > effect
> > > > a
> > > > > > >
> > > > > > > change
> > > > > > >
> > > > > > > > > either outcome
> > > > > > > > >
> > > > > > > > > +1: Never respin with the same version number, always
> > increment
> > > > the
> > > > > > > > > version for a respin
> > > > > > > > > 0: Don't care
> > > > > > > > > -1: Always respin with the same version number until that
> > > version
> > > > > > >
> > > > > > > number
> > > > > > >
> > > > > > > > > gets released
> > > > > > > > >
> > > > > > > > > This vote will be open for 72 hours. A Majority of PMC
> votes
> > > > > greater
> > > > > > >
> > > > > > > that
> > > > > > >
> > > > > > > > > 3 will be deemed as decisive in either direction (i.e. if
> the
> > > sum
> > > > > is <
> > > > > > >
> > > > > > > -3
> > > > > > >
> > > > > > > > > or > +3 then there is a documented result)
> > > > > > > > >
> > > > > > > > > For any releases in progress at this point in time, it is
> up
> > to
> > > > the
> > > > > > > > > release manager to decide what to do if they need to do a
> > > respin.
> > > > > > > > >
> > > > > > > > > -Stephen
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Chris Graham <ch...@gmail.com>]

Fred, you're the one who mentioned git in that post.

Please remember what stephen pointed out (which I thought was rather nicely
worded): [paraphrased]

                The real release is the source bundle, and the tags are
merely a convienance to a developer.

-Chris


On Mon, Jun 3, 2013 at 10:44 AM, Fred Cooke <fr...@gmail.com> wrote:

> Although I prefer to use Git, it's totally irrelevant. I'm unsure how you
> came to the conclusion that I thought this was anything to do with Git.
> Subversion tags, though mutable, should not EVER be committed against or in
> any other way modified. Doing so is the behaviour of a (bad quality) grad
> student, not a software development professional!
>
> On Mon, Jun 3, 2013 at 2:31 AM, Chris Graham <ch...@gmail.com> wrote:
>
> > Fred,
> >
> > We are talking more process here. Not the specifics of an individual SCM,
> > not everything is in git. We are still talking about the abstraction api
> > that the maven-scm handlers provide, of which git is but one.
> >
> > -Chris
> >
> >
> > On Mon, Jun 3, 2013 at 4:42 AM, Fred Cooke <fr...@gmail.com> wrote:
> >
> > > > from my experience, even if this question is not absolutely
> > scm-specific,
> > > > git
> > > > brings us a new problem we didn't have with svn: once a tag is set on
> > the
> > > > canonical repo and replicated on developers' repos, it is not
> > > automatically
> > > > updated if updated in the canonical
> > > >
> > >
> > > Git brings you no such "problem", it simply exposes your extremely poor
> > > practices... A tag should, and in any sane place is, permanent and
> > > irrevocable.
> > >
> > > On another note, the veto by -1 vote mechanism is a great idea for a
> > > release, but a terrible idea for a principle like this. For a release
> it
> > > requires a justification, for this it's just "my opinion" overriding
> one
> > of
> > > Maven's core principals.
> > >
> > > Stagnation wins.
> > >
> > > Fred.
> > >
> > >
> > > >
> > > > but I may miss some git-fu once again...
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> > > > > >but as I see, there seems to be a consensus around a 2-sided rule:
> > > > > >- don't reuse version number for pre-releases (RC, etc)
> > > > > >- reuse version number for actual releases
> > > > >
> > > > > Not sure how I feel about that.
> > > > >
> > > > > alpha/beta/RCx etc, they are all still valid version nos, so I
> think
> > > that
> > > > > the no re-spin rule should still apply in the same manner.
> > > > >
> > > > > -Chris
> > > > >
> > > > > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <
> herve.boutemy@free.fr
> > >
> > > > wrote:
> > > > > > yes, the vote for one unique rule is clearly "-1"
> > > > > >
> > > > > > but as I see, there seems to be a consensus around a 2-sided
> rule:
> > > > > > - don't reuse version number for pre-releases (RC, etc)
> > > > > > - reuse version number for actual releases
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> > > > > > > I will need to recheck the tally, but I think the result is -3
> > > > > > >
> > > > > > > So looks like we will be reusing version numbers on respins
> > > > > > >
> > > > > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
> > > > > > > > We have been using a policy of only making releases without
> > > > skipping
> > > > > > > > version numbers, e.g.
> > > > > > > >
> > > > > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > > > > > > >
> > > > > > > > Whereby if there is something wrong with the artifacts staged
> > for
> > > > > >
> > > > > > release,
> > > > > >
> > > > > > > > we drop the staging repo, delete the tag, roll back the
> > version,
> > > > and
> > > > > >
> > > > > > run
> > > > > >
> > > > > > > > again.
> > > > > > > >
> > > > > > > > This vote is to change the policy to:
> > > > > > > >
> > > > > > > > drop the staging repo, document the release as not released,
> > and
> > > > run
> > > > > >
> > > > > > with
> > > > > >
> > > > > > > > the next version.
> > > > > > > >
> > > > > > > > Under this new proposal, if the staged artifacts for 3.1.0
> fail
> > > to
> > > > > > > > meet
> > > > > > > > the release criteria, then the artifacts would be dropped
> from
> > > the
> > > > > >
> > > > > > staging
> > > > > >
> > > > > > > > repository and never see the light of day. The tag would
> remain
> > > in
> > > > > > > > SCM,
> > > > > > > > and
> > > > > > > > we would document (somewhere) that the release was cancelled.
> > The
> > > > > >
> > > > > > "respin"
> > > > > >
> > > > > > > > would have version number 3.1.1 and there would never be a
> > 3.1.0.
> > > > > > > >
> > > > > > > > This change could mean that the first actual release of 3.1.x
> > > might
> > > > > >
> > > > > > end up
> > > > > >
> > > > > > > > being 3.1.67 (though I personally view that as unlikely, and
> in
> > > the
> > > > > > > > context
> > > > > > > > of 3.1.x I think we are very nearly there)
> > > > > >
> > > > > > > > Please Note:
> > > > > >
> > > >
> > >
> >
> http://maven.apache.org/developers/release/maven-project-release-procedure
> > > > > >
> > > > > > > > .html#Check_the_vote_resultsdoes not actually specify what it
> > > > means by
> > > > > > > > "the process will need to be restarted" so this vote will
> > effect
> > > a
> > > > > >
> > > > > > change
> > > > > >
> > > > > > > > either outcome
> > > > > > > >
> > > > > > > > +1: Never respin with the same version number, always
> increment
> > > the
> > > > > > > > version for a respin
> > > > > > > > 0: Don't care
> > > > > > > > -1: Always respin with the same version number until that
> > version
> > > > > >
> > > > > > number
> > > > > >
> > > > > > > > gets released
> > > > > > > >
> > > > > > > > This vote will be open for 72 hours. A Majority of PMC votes
> > > > greater
> > > > > >
> > > > > > that
> > > > > >
> > > > > > > > 3 will be deemed as decisive in either direction (i.e. if the
> > sum
> > > > is <
> > > > > >
> > > > > > -3
> > > > > >
> > > > > > > > or > +3 then there is a documented result)
> > > > > > > >
> > > > > > > > For any releases in progress at this point in time, it is up
> to
> > > the
> > > > > > > > release manager to decide what to do if they need to do a
> > respin.
> > > > > > > >
> > > > > > > > -Stephen
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Fred Cooke <fr...@gmail.com>]

Although I prefer to use Git, it's totally irrelevant. I'm unsure how you
came to the conclusion that I thought this was anything to do with Git.
Subversion tags, though mutable, should not EVER be committed against or in
any other way modified. Doing so is the behaviour of a (bad quality) grad
student, not a software development professional!

On Mon, Jun 3, 2013 at 2:31 AM, Chris Graham <ch...@gmail.com> wrote:

> Fred,
>
> We are talking more process here. Not the specifics of an individual SCM,
> not everything is in git. We are still talking about the abstraction api
> that the maven-scm handlers provide, of which git is but one.
>
> -Chris
>
>
> On Mon, Jun 3, 2013 at 4:42 AM, Fred Cooke <fr...@gmail.com> wrote:
>
> > > from my experience, even if this question is not absolutely
> scm-specific,
> > > git
> > > brings us a new problem we didn't have with svn: once a tag is set on
> the
> > > canonical repo and replicated on developers' repos, it is not
> > automatically
> > > updated if updated in the canonical
> > >
> >
> > Git brings you no such "problem", it simply exposes your extremely poor
> > practices... A tag should, and in any sane place is, permanent and
> > irrevocable.
> >
> > On another note, the veto by -1 vote mechanism is a great idea for a
> > release, but a terrible idea for a principle like this. For a release it
> > requires a justification, for this it's just "my opinion" overriding one
> of
> > Maven's core principals.
> >
> > Stagnation wins.
> >
> > Fred.
> >
> >
> > >
> > > but I may miss some git-fu once again...
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> > > > >but as I see, there seems to be a consensus around a 2-sided rule:
> > > > >- don't reuse version number for pre-releases (RC, etc)
> > > > >- reuse version number for actual releases
> > > >
> > > > Not sure how I feel about that.
> > > >
> > > > alpha/beta/RCx etc, they are all still valid version nos, so I think
> > that
> > > > the no re-spin rule should still apply in the same manner.
> > > >
> > > > -Chris
> > > >
> > > > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <herve.boutemy@free.fr
> >
> > > wrote:
> > > > > yes, the vote for one unique rule is clearly "-1"
> > > > >
> > > > > but as I see, there seems to be a consensus around a 2-sided rule:
> > > > > - don't reuse version number for pre-releases (RC, etc)
> > > > > - reuse version number for actual releases
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> > > > > > I will need to recheck the tally, but I think the result is -3
> > > > > >
> > > > > > So looks like we will be reusing version numbers on respins
> > > > > >
> > > > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
> > > > > > > We have been using a policy of only making releases without
> > > skipping
> > > > > > > version numbers, e.g.
> > > > > > >
> > > > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > > > > > >
> > > > > > > Whereby if there is something wrong with the artifacts staged
> for
> > > > >
> > > > > release,
> > > > >
> > > > > > > we drop the staging repo, delete the tag, roll back the
> version,
> > > and
> > > > >
> > > > > run
> > > > >
> > > > > > > again.
> > > > > > >
> > > > > > > This vote is to change the policy to:
> > > > > > >
> > > > > > > drop the staging repo, document the release as not released,
> and
> > > run
> > > > >
> > > > > with
> > > > >
> > > > > > > the next version.
> > > > > > >
> > > > > > > Under this new proposal, if the staged artifacts for 3.1.0 fail
> > to
> > > > > > > meet
> > > > > > > the release criteria, then the artifacts would be dropped from
> > the
> > > > >
> > > > > staging
> > > > >
> > > > > > > repository and never see the light of day. The tag would remain
> > in
> > > > > > > SCM,
> > > > > > > and
> > > > > > > we would document (somewhere) that the release was cancelled.
> The
> > > > >
> > > > > "respin"
> > > > >
> > > > > > > would have version number 3.1.1 and there would never be a
> 3.1.0.
> > > > > > >
> > > > > > > This change could mean that the first actual release of 3.1.x
> > might
> > > > >
> > > > > end up
> > > > >
> > > > > > > being 3.1.67 (though I personally view that as unlikely, and in
> > the
> > > > > > > context
> > > > > > > of 3.1.x I think we are very nearly there)
> > > > >
> > > > > > > Please Note:
> > > > >
> > >
> >
> http://maven.apache.org/developers/release/maven-project-release-procedure
> > > > >
> > > > > > > .html#Check_the_vote_resultsdoes not actually specify what it
> > > means by
> > > > > > > "the process will need to be restarted" so this vote will
> effect
> > a
> > > > >
> > > > > change
> > > > >
> > > > > > > either outcome
> > > > > > >
> > > > > > > +1: Never respin with the same version number, always increment
> > the
> > > > > > > version for a respin
> > > > > > > 0: Don't care
> > > > > > > -1: Always respin with the same version number until that
> version
> > > > >
> > > > > number
> > > > >
> > > > > > > gets released
> > > > > > >
> > > > > > > This vote will be open for 72 hours. A Majority of PMC votes
> > > greater
> > > > >
> > > > > that
> > > > >
> > > > > > > 3 will be deemed as decisive in either direction (i.e. if the
> sum
> > > is <
> > > > >
> > > > > -3
> > > > >
> > > > > > > or > +3 then there is a documented result)
> > > > > > >
> > > > > > > For any releases in progress at this point in time, it is up to
> > the
> > > > > > > release manager to decide what to do if they need to do a
> respin.
> > > > > > >
> > > > > > > -Stephen
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Chris Graham <ch...@gmail.com>]

Fred,

We are talking more process here. Not the specifics of an individual SCM,
not everything is in git. We are still talking about the abstraction api
that the maven-scm handlers provide, of which git is but one.

-Chris


On Mon, Jun 3, 2013 at 4:42 AM, Fred Cooke <fr...@gmail.com> wrote:

> > from my experience, even if this question is not absolutely scm-specific,
> > git
> > brings us a new problem we didn't have with svn: once a tag is set on the
> > canonical repo and replicated on developers' repos, it is not
> automatically
> > updated if updated in the canonical
> >
>
> Git brings you no such "problem", it simply exposes your extremely poor
> practices... A tag should, and in any sane place is, permanent and
> irrevocable.
>
> On another note, the veto by -1 vote mechanism is a great idea for a
> release, but a terrible idea for a principle like this. For a release it
> requires a justification, for this it's just "my opinion" overriding one of
> Maven's core principals.
>
> Stagnation wins.
>
> Fred.
>
>
> >
> > but I may miss some git-fu once again...
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> > > >but as I see, there seems to be a consensus around a 2-sided rule:
> > > >- don't reuse version number for pre-releases (RC, etc)
> > > >- reuse version number for actual releases
> > >
> > > Not sure how I feel about that.
> > >
> > > alpha/beta/RCx etc, they are all still valid version nos, so I think
> that
> > > the no re-spin rule should still apply in the same manner.
> > >
> > > -Chris
> > >
> > > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <he...@free.fr>
> > wrote:
> > > > yes, the vote for one unique rule is clearly "-1"
> > > >
> > > > but as I see, there seems to be a consensus around a 2-sided rule:
> > > > - don't reuse version number for pre-releases (RC, etc)
> > > > - reuse version number for actual releases
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> > > > > I will need to recheck the tally, but I think the result is -3
> > > > >
> > > > > So looks like we will be reusing version numbers on respins
> > > > >
> > > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
> > > > > > We have been using a policy of only making releases without
> > skipping
> > > > > > version numbers, e.g.
> > > > > >
> > > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > > > > >
> > > > > > Whereby if there is something wrong with the artifacts staged for
> > > >
> > > > release,
> > > >
> > > > > > we drop the staging repo, delete the tag, roll back the version,
> > and
> > > >
> > > > run
> > > >
> > > > > > again.
> > > > > >
> > > > > > This vote is to change the policy to:
> > > > > >
> > > > > > drop the staging repo, document the release as not released, and
> > run
> > > >
> > > > with
> > > >
> > > > > > the next version.
> > > > > >
> > > > > > Under this new proposal, if the staged artifacts for 3.1.0 fail
> to
> > > > > > meet
> > > > > > the release criteria, then the artifacts would be dropped from
> the
> > > >
> > > > staging
> > > >
> > > > > > repository and never see the light of day. The tag would remain
> in
> > > > > > SCM,
> > > > > > and
> > > > > > we would document (somewhere) that the release was cancelled. The
> > > >
> > > > "respin"
> > > >
> > > > > > would have version number 3.1.1 and there would never be a 3.1.0.
> > > > > >
> > > > > > This change could mean that the first actual release of 3.1.x
> might
> > > >
> > > > end up
> > > >
> > > > > > being 3.1.67 (though I personally view that as unlikely, and in
> the
> > > > > > context
> > > > > > of 3.1.x I think we are very nearly there)
> > > >
> > > > > > Please Note:
> > > >
> >
> http://maven.apache.org/developers/release/maven-project-release-procedure
> > > >
> > > > > > .html#Check_the_vote_resultsdoes not actually specify what it
> > means by
> > > > > > "the process will need to be restarted" so this vote will effect
> a
> > > >
> > > > change
> > > >
> > > > > > either outcome
> > > > > >
> > > > > > +1: Never respin with the same version number, always increment
> the
> > > > > > version for a respin
> > > > > > 0: Don't care
> > > > > > -1: Always respin with the same version number until that version
> > > >
> > > > number
> > > >
> > > > > > gets released
> > > > > >
> > > > > > This vote will be open for 72 hours. A Majority of PMC votes
> > greater
> > > >
> > > > that
> > > >
> > > > > > 3 will be deemed as decisive in either direction (i.e. if the sum
> > is <
> > > >
> > > > -3
> > > >
> > > > > > or > +3 then there is a documented result)
> > > > > >
> > > > > > For any releases in progress at this point in time, it is up to
> the
> > > > > > release manager to decide what to do if they need to do a respin.
> > > > > >
> > > > > > -Stephen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Fred Cooke <fr...@gmail.com>]

> from my experience, even if this question is not absolutely scm-specific,
> git
> brings us a new problem we didn't have with svn: once a tag is set on the
> canonical repo and replicated on developers' repos, it is not automatically
> updated if updated in the canonical
>

Git brings you no such "problem", it simply exposes your extremely poor
practices... A tag should, and in any sane place is, permanent and
irrevocable.

On another note, the veto by -1 vote mechanism is a great idea for a
release, but a terrible idea for a principle like this. For a release it
requires a justification, for this it's just "my opinion" overriding one of
Maven's core principals.

Stagnation wins.

Fred.


>
> but I may miss some git-fu once again...
>
> Regards,
>
> Hervé
>
> Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> > >but as I see, there seems to be a consensus around a 2-sided rule:
> > >- don't reuse version number for pre-releases (RC, etc)
> > >- reuse version number for actual releases
> >
> > Not sure how I feel about that.
> >
> > alpha/beta/RCx etc, they are all still valid version nos, so I think that
> > the no re-spin rule should still apply in the same manner.
> >
> > -Chris
> >
> > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <he...@free.fr>
> wrote:
> > > yes, the vote for one unique rule is clearly "-1"
> > >
> > > but as I see, there seems to be a consensus around a 2-sided rule:
> > > - don't reuse version number for pre-releases (RC, etc)
> > > - reuse version number for actual releases
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> > > > I will need to recheck the tally, but I think the result is -3
> > > >
> > > > So looks like we will be reusing version numbers on respins
> > > >
> > > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
> > > > > We have been using a policy of only making releases without
> skipping
> > > > > version numbers, e.g.
> > > > >
> > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > > > >
> > > > > Whereby if there is something wrong with the artifacts staged for
> > >
> > > release,
> > >
> > > > > we drop the staging repo, delete the tag, roll back the version,
> and
> > >
> > > run
> > >
> > > > > again.
> > > > >
> > > > > This vote is to change the policy to:
> > > > >
> > > > > drop the staging repo, document the release as not released, and
> run
> > >
> > > with
> > >
> > > > > the next version.
> > > > >
> > > > > Under this new proposal, if the staged artifacts for 3.1.0 fail to
> > > > > meet
> > > > > the release criteria, then the artifacts would be dropped from the
> > >
> > > staging
> > >
> > > > > repository and never see the light of day. The tag would remain in
> > > > > SCM,
> > > > > and
> > > > > we would document (somewhere) that the release was cancelled. The
> > >
> > > "respin"
> > >
> > > > > would have version number 3.1.1 and there would never be a 3.1.0.
> > > > >
> > > > > This change could mean that the first actual release of 3.1.x might
> > >
> > > end up
> > >
> > > > > being 3.1.67 (though I personally view that as unlikely, and in the
> > > > > context
> > > > > of 3.1.x I think we are very nearly there)
> > >
> > > > > Please Note:
> > >
> http://maven.apache.org/developers/release/maven-project-release-procedure
> > >
> > > > > .html#Check_the_vote_resultsdoes not actually specify what it
> means by
> > > > > "the process will need to be restarted" so this vote will effect a
> > >
> > > change
> > >
> > > > > either outcome
> > > > >
> > > > > +1: Never respin with the same version number, always increment the
> > > > > version for a respin
> > > > > 0: Don't care
> > > > > -1: Always respin with the same version number until that version
> > >
> > > number
> > >
> > > > > gets released
> > > > >
> > > > > This vote will be open for 72 hours. A Majority of PMC votes
> greater
> > >
> > > that
> > >
> > > > > 3 will be deemed as decisive in either direction (i.e. if the sum
> is <
> > >
> > > -3
> > >
> > > > > or > +3 then there is a documented result)
> > > > >
> > > > > For any releases in progress at this point in time, it is up to the
> > > > > release manager to decide what to do if they need to do a respin.
> > > > >
> > > > > -Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Hervé BOUTEMY <he...@free.fr>]

from a pure technical perspective, yes: a release is a release

but from recent experience, making such difference between pre-releases and 
actual releases could give us some flexibility without much disturbance

from my experience, even if this question is not absolutely scm-specific, git 
brings us a new problem we didn't have with svn: once a tag is set on the 
canonical repo and replicated on developers' repos, it is not automatically 
updated if updated in the canonical

but I may miss some git-fu once again...

Regards,

Hervé

Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
> >but as I see, there seems to be a consensus around a 2-sided rule:
> >- don't reuse version number for pre-releases (RC, etc)
> >- reuse version number for actual releases
> 
> Not sure how I feel about that.
> 
> alpha/beta/RCx etc, they are all still valid version nos, so I think that
> the no re-spin rule should still apply in the same manner.
> 
> -Chris
> 
> On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> > yes, the vote for one unique rule is clearly "-1"
> > 
> > but as I see, there seems to be a consensus around a 2-sided rule:
> > - don't reuse version number for pre-releases (RC, etc)
> > - reuse version number for actual releases
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> > > I will need to recheck the tally, but I think the result is -3
> > > 
> > > So looks like we will be reusing version numbers on respins
> > > 
> > > On Wednesday, 29 May 2013, Stephen Connolly wrote:
> > > > We have been using a policy of only making releases without skipping
> > > > version numbers, e.g.
> > > > 
> > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > > > 
> > > > Whereby if there is something wrong with the artifacts staged for
> > 
> > release,
> > 
> > > > we drop the staging repo, delete the tag, roll back the version, and
> > 
> > run
> > 
> > > > again.
> > > > 
> > > > This vote is to change the policy to:
> > > > 
> > > > drop the staging repo, document the release as not released, and run
> > 
> > with
> > 
> > > > the next version.
> > > > 
> > > > Under this new proposal, if the staged artifacts for 3.1.0 fail to
> > > > meet
> > > > the release criteria, then the artifacts would be dropped from the
> > 
> > staging
> > 
> > > > repository and never see the light of day. The tag would remain in
> > > > SCM,
> > > > and
> > > > we would document (somewhere) that the release was cancelled. The
> > 
> > "respin"
> > 
> > > > would have version number 3.1.1 and there would never be a 3.1.0.
> > > > 
> > > > This change could mean that the first actual release of 3.1.x might
> > 
> > end up
> > 
> > > > being 3.1.67 (though I personally view that as unlikely, and in the
> > > > context
> > > > of 3.1.x I think we are very nearly there)
> > 
> > > > Please Note:
> > http://maven.apache.org/developers/release/maven-project-release-procedure
> > 
> > > > .html#Check_the_vote_resultsdoes not actually specify what it means by
> > > > "the process will need to be restarted" so this vote will effect a
> > 
> > change
> > 
> > > > either outcome
> > > > 
> > > > +1: Never respin with the same version number, always increment the
> > > > version for a respin
> > > > 0: Don't care
> > > > -1: Always respin with the same version number until that version
> > 
> > number
> > 
> > > > gets released
> > > > 
> > > > This vote will be open for 72 hours. A Majority of PMC votes greater
> > 
> > that
> > 
> > > > 3 will be deemed as decisive in either direction (i.e. if the sum is <
> > 
> > -3
> > 
> > > > or > +3 then there is a documented result)
> > > > 
> > > > For any releases in progress at this point in time, it is up to the
> > > > release manager to decide what to do if they need to do a respin.
> > > > 
> > > > -Stephen

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Chris Graham <ch...@gmail.com>]

>but as I see, there seems to be a consensus around a 2-sided rule:
>- don't reuse version number for pre-releases (RC, etc)
>- reuse version number for actual releases

Not sure how I feel about that.

alpha/beta/RCx etc, they are all still valid version nos, so I think that
the no re-spin rule should still apply in the same manner.

-Chris



On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <he...@free.fr> wrote:

> yes, the vote for one unique rule is clearly "-1"
>
> but as I see, there seems to be a consensus around a 2-sided rule:
> - don't reuse version number for pre-releases (RC, etc)
> - reuse version number for actual releases
>
> Regards,
>
> Hervé
>
> Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> > I will need to recheck the tally, but I think the result is -3
> >
> > So looks like we will be reusing version numbers on respins
> >
> > On Wednesday, 29 May 2013, Stephen Connolly wrote:
> > > We have been using a policy of only making releases without skipping
> > > version numbers, e.g.
> > >
> > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > >
> > > Whereby if there is something wrong with the artifacts staged for
> release,
> > > we drop the staging repo, delete the tag, roll back the version, and
> run
> > > again.
> > >
> > > This vote is to change the policy to:
> > >
> > > drop the staging repo, document the release as not released, and run
> with
> > > the next version.
> > >
> > > Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
> > > the release criteria, then the artifacts would be dropped from the
> staging
> > > repository and never see the light of day. The tag would remain in SCM,
> > > and
> > > we would document (somewhere) that the release was cancelled. The
> "respin"
> > > would have version number 3.1.1 and there would never be a 3.1.0.
> > >
> > > This change could mean that the first actual release of 3.1.x might
> end up
> > > being 3.1.67 (though I personally view that as unlikely, and in the
> > > context
> > > of 3.1.x I think we are very nearly there)
> > >
> > > Please Note:
> > >
> http://maven.apache.org/developers/release/maven-project-release-procedure
> > > .html#Check_the_vote_resultsdoes not actually specify what it means by
> > > "the process will need to be restarted" so this vote will effect a
> change
> > > either outcome
> > >
> > > +1: Never respin with the same version number, always increment the
> > > version for a respin
> > > 0: Don't care
> > > -1: Always respin with the same version number until that version
> number
> > > gets released
> > >
> > > This vote will be open for 72 hours. A Majority of PMC votes greater
> that
> > > 3 will be deemed as decisive in either direction (i.e. if the sum is <
> -3
> > > or > +3 then there is a documented result)
> > >
> > > For any releases in progress at this point in time, it is up to the
> > > release manager to decide what to do if they need to do a respin.
> > >
> > > -Stephen
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Hervé BOUTEMY <he...@free.fr>]

yes, the vote for one unique rule is clearly "-1"

but as I see, there seems to be a consensus around a 2-sided rule:
- don't reuse version number for pre-releases (RC, etc)
- reuse version number for actual releases

Regards,

Hervé

Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
> I will need to recheck the tally, but I think the result is -3
> 
> So looks like we will be reusing version numbers on respins
> 
> On Wednesday, 29 May 2013, Stephen Connolly wrote:
> > We have been using a policy of only making releases without skipping
> > version numbers, e.g.
> > 
> > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > 
> > Whereby if there is something wrong with the artifacts staged for release,
> > we drop the staging repo, delete the tag, roll back the version, and run
> > again.
> > 
> > This vote is to change the policy to:
> > 
> > drop the staging repo, document the release as not released, and run with
> > the next version.
> > 
> > Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
> > the release criteria, then the artifacts would be dropped from the staging
> > repository and never see the light of day. The tag would remain in SCM,
> > and
> > we would document (somewhere) that the release was cancelled. The "respin"
> > would have version number 3.1.1 and there would never be a 3.1.0.
> > 
> > This change could mean that the first actual release of 3.1.x might end up
> > being 3.1.67 (though I personally view that as unlikely, and in the
> > context
> > of 3.1.x I think we are very nearly there)
> > 
> > Please Note:
> > http://maven.apache.org/developers/release/maven-project-release-procedure
> > .html#Check_the_vote_resultsdoes not actually specify what it means by
> > "the process will need to be restarted" so this vote will effect a change
> > either outcome
> > 
> > +1: Never respin with the same version number, always increment the
> > version for a respin
> > 0: Don't care
> > -1: Always respin with the same version number until that version number
> > gets released
> > 
> > This vote will be open for 72 hours. A Majority of PMC votes greater that
> > 3 will be deemed as decisive in either direction (i.e. if the sum is < -3
> > or > +3 then there is a documented result)
> > 
> > For any releases in progress at this point in time, it is up to the
> > release manager to decide what to do if they need to do a respin.
> > 
> > -Stephen

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Stephen Connolly <st...@gmail.com>]

I will need to recheck the tally, but I think the result is -3

So looks like we will be reusing version numbers on respins

On Wednesday, 29 May 2013, Stephen Connolly wrote:

> We have been using a policy of only making releases without skipping
> version numbers, e.g.
>
> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>
> Whereby if there is something wrong with the artifacts staged for release,
> we drop the staging repo, delete the tag, roll back the version, and run
> again.
>
> This vote is to change the policy to:
>
> drop the staging repo, document the release as not released, and run with
> the next version.
>
> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
> the release criteria, then the artifacts would be dropped from the staging
> repository and never see the light of day. The tag would remain in SCM, and
> we would document (somewhere) that the release was cancelled. The "respin"
> would have version number 3.1.1 and there would never be a 3.1.0.
>
> This change could mean that the first actual release of 3.1.x might end up
> being 3.1.67 (though I personally view that as unlikely, and in the context
> of 3.1.x I think we are very nearly there)
>
> Please Note:
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes not actually specify what it means by "the process will need to be
> restarted" so this vote will effect a change either outcome
>
> +1: Never respin with the same version number, always increment the
> version for a respin
> 0: Don't care
> -1: Always respin with the same version number until that version number
> gets released
>
> This vote will be open for 72 hours. A Majority of PMC votes greater that
> 3 will be deemed as decisive in either direction (i.e. if the sum is < -3
> or > +3 then there is a documented result)
>
> For any releases in progress at this point in time, it is up to the
> release manager to decide what to do if they need to do a respin.
>
> -Stephen
>


-- 
Sent from my phone

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Kristian Rosenvold <kr...@zenior.no>]

-1

Den 29. mai 2013 kl. 12:04 skrev Tony Chemit <ch...@codelutin.com>:

> On Wed, 29 May 2013 11:01:25 +0100
> Stephen Connolly <st...@gmail.com> wrote:
>
> +1 (at last ;))
>
> tony (non binding)
>
>> +1 (binding)
>>
>>
>> On 29 May 2013 11:01, Stephen Connolly <st...@gmail.com>wrote:
>>
>>> We have been using a policy of only making releases without skipping
>>> version numbers, e.g.
>>>
>>> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>>>
>>> Whereby if there is something wrong with the artifacts staged for release,
>>> we drop the staging repo, delete the tag, roll back the version, and run
>>> again.
>>>
>>> This vote is to change the policy to:
>>>
>>> drop the staging repo, document the release as not released, and run with
>>> the next version.
>>>
>>> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
>>> the release criteria, then the artifacts would be dropped from the staging
>>> repository and never see the light of day. The tag would remain in SCM, and
>>> we would document (somewhere) that the release was cancelled. The "respin"
>>> would have version number 3.1.1 and there would never be a 3.1.0.
>>>
>>> This change could mean that the first actual release of 3.1.x might end up
>>> being 3.1.67 (though I personally view that as unlikely, and in the context
>>> of 3.1.x I think we are very nearly there)
>>>
>>> Please Note:
>>> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes not actually specify what it means by "the process will need to be
>>> restarted" so this vote will effect a change either outcome
>>>
>>> +1: Never respin with the same version number, always increment the
>>> version for a respin
>>> 0: Don't care
>>> -1: Always respin with the same version number until that version number
>>> gets released
>>>
>>> This vote will be open for 72 hours. A Majority of PMC votes greater that
>>> 3 will be deemed as decisive in either direction (i.e. if the sum is < -3
>>> or > +3 then there is a documented result)
>>>
>>> For any releases in progress at this point in time, it is up to the
>>> release manager to decide what to do if they need to do a respin.
>>>
>>> -Stephen
>
>
>
> --
> Tony Chemit
> --------------------
> tél: +33 (0) 2 40 50 29 28
> email: chemit@codelutin.com
> http://www.codelutin.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Tony Chemit <ch...@codelutin.com>]

On Wed, 29 May 2013 11:01:25 +0100
Stephen Connolly <st...@gmail.com> wrote:

+1 (at last ;))

tony (non binding)

> +1 (binding)
> 
> 
> On 29 May 2013 11:01, Stephen Connolly <st...@gmail.com>wrote:
> 
> > We have been using a policy of only making releases without skipping
> > version numbers, e.g.
> >
> > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> >
> > Whereby if there is something wrong with the artifacts staged for release,
> > we drop the staging repo, delete the tag, roll back the version, and run
> > again.
> >
> > This vote is to change the policy to:
> >
> > drop the staging repo, document the release as not released, and run with
> > the next version.
> >
> > Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
> > the release criteria, then the artifacts would be dropped from the staging
> > repository and never see the light of day. The tag would remain in SCM, and
> > we would document (somewhere) that the release was cancelled. The "respin"
> > would have version number 3.1.1 and there would never be a 3.1.0.
> >
> > This change could mean that the first actual release of 3.1.x might end up
> > being 3.1.67 (though I personally view that as unlikely, and in the context
> > of 3.1.x I think we are very nearly there)
> >
> > Please Note:
> > http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes not actually specify what it means by "the process will need to be
> > restarted" so this vote will effect a change either outcome
> >
> > +1: Never respin with the same version number, always increment the
> > version for a respin
> > 0: Don't care
> > -1: Always respin with the same version number until that version number
> > gets released
> >
> > This vote will be open for 72 hours. A Majority of PMC votes greater that
> > 3 will be deemed as decisive in either direction (i.e. if the sum is < -3
> > or > +3 then there is a documented result)
> >
> > For any releases in progress at this point in time, it is up to the
> > release manager to decide what to do if they need to do a respin.
> >
> > -Stephen
> >



-- 
Tony Chemit
--------------------
tél: +33 (0) 2 40 50 29 28
email: chemit@codelutin.com
http://www.codelutin.com

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Stephen Connolly <st...@gmail.com>]

+1 (binding)


On 29 May 2013 11:01, Stephen Connolly <st...@gmail.com>wrote:

> We have been using a policy of only making releases without skipping
> version numbers, e.g.
>
> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>
> Whereby if there is something wrong with the artifacts staged for release,
> we drop the staging repo, delete the tag, roll back the version, and run
> again.
>
> This vote is to change the policy to:
>
> drop the staging repo, document the release as not released, and run with
> the next version.
>
> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
> the release criteria, then the artifacts would be dropped from the staging
> repository and never see the light of day. The tag would remain in SCM, and
> we would document (somewhere) that the release was cancelled. The "respin"
> would have version number 3.1.1 and there would never be a 3.1.0.
>
> This change could mean that the first actual release of 3.1.x might end up
> being 3.1.67 (though I personally view that as unlikely, and in the context
> of 3.1.x I think we are very nearly there)
>
> Please Note:
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes not actually specify what it means by "the process will need to be
> restarted" so this vote will effect a change either outcome
>
> +1: Never respin with the same version number, always increment the
> version for a respin
> 0: Don't care
> -1: Always respin with the same version number until that version number
> gets released
>
> This vote will be open for 72 hours. A Majority of PMC votes greater that
> 3 will be deemed as decisive in either direction (i.e. if the sum is < -3
> or > +3 then there is a documented result)
>
> For any releases in progress at this point in time, it is up to the
> release manager to decide what to do if they need to do a respin.
>
> -Stephen
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Lukas Theussl <lt...@apache.org>]

-1 (non-binding)

-Lukas


On 05/29/2013 12:01 PM, Stephen Connolly wrote:
> We have been using a policy of only making releases without skipping
> version numbers, e.g.
> 
> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> 
> Whereby if there is something wrong with the artifacts staged for release,
> we drop the staging repo, delete the tag, roll back the version, and run
> again.
> 
> This vote is to change the policy to:
> 
> drop the staging repo, document the release as not released, and run with
> the next version.
> 
> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the
> release criteria, then the artifacts would be dropped from the staging
> repository and never see the light of day. The tag would remain in SCM, and
> we would document (somewhere) that the release was cancelled. The "respin"
> would have version number 3.1.1 and there would never be a 3.1.0.
> 
> This change could mean that the first actual release of 3.1.x might end up
> being 3.1.67 (though I personally view that as unlikely, and in the context
> of 3.1.x I think we are very nearly there)
> 
> Please Note:
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
> not actually specify what it means by "the process will need to be
> restarted" so this vote will effect a change either outcome
> 
> +1: Never respin with the same version number, always increment the version
> for a respin
> 0: Don't care
> -1: Always respin with the same version number until that version number
> gets released
> 
> This vote will be open for 72 hours. A Majority of PMC votes greater that 3
> will be deemed as decisive in either direction (i.e. if the sum is < -3 or
>> +3 then there is a documented result)
> 
> For any releases in progress at this point in time, it is up to the release
> manager to decide what to do if they need to do a respin.
> 
> -Stephen
> 

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Mirko Friedenhagen <mf...@gmail.com>]

Non-bindingly:
+1 for pre-releases
-1 for actual releases
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/


On Wed, May 29, 2013 at 10:00 PM, Baptiste MATHUS <bm...@batmat.net> wrote:
> You're right, my bad. I just re-read the details in Stephen's original mail.
>
> So I'm also:
> +1 for pre-releases, dropping everything to reuse numbers is not worth the
> hassle
> -1 for actual releases: it would create more mess imo for end users if
> there's many bizarre jumps in numbering
>
>
> 2013/5/29 Fred Cooke <fr...@gmail.com>
>
>> "This vote is to change the policy to:
>>
>> drop the staging repo, document the release as not released, and run with
>> the next version."
>>
>> On Wed, May 29, 2013 at 9:54 PM, Baptiste MATHUS <bm...@batmat.net>
>> wrote:
>>
>> > Well, from the wording of the VOTE question and what I've read from you
>> > Fred in the past, shouldn't actually be a -1 from you here?
>> >
>> > What I read is "Should we respin CANCELLED releases with the same version
>> > number?" then
>> > +1 = current way of working, just drop the release and re-release
>> (possibly
>> > with "take n" in the subject mail, and so on)
>> > -1 = please do not reuse number, numbers are cheap
>> >
>> > Was it what you intended to vote on, and was it how Stephen was thinking
>> to
>> > orient the sentence and the +1/-1 meaning?
>> >
>> >
>> > 2013/5/29 Fred Cooke <fr...@gmail.com>
>> >
>> > > +1(million) non-binding, but if you want, I'll have your children if
>> you
>> > > make this extremely positive change!!!! <3
>> > >
>> > > On Wed, May 29, 2013 at 12:31 PM, Jörg Schaible <
>> > > Joerg.Schaible@scalaris.com
>> > > > wrote:
>> > >
>> > > > -1 (nb)
>> > > >
>> > > > Stephen Connolly wrote:
>> > > >
>> > > > > We have been using a policy of only making releases without
>> skipping
>> > > > > version numbers, e.g.
>> > > > >
>> > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>> > > > >
>> > > > > Whereby if there is something wrong with the artifacts staged for
>> > > > release,
>> > > > > we drop the staging repo, delete the tag, roll back the version,
>> and
>> > > run
>> > > > > again.
>> > > > >
>> > > > > This vote is to change the policy to:
>> > > > >
>> > > > > drop the staging repo, document the release as not released, and
>> run
>> > > with
>> > > > > the next version.
>> > > > >
>> > > > > Under this new proposal, if the staged artifacts for 3.1.0 fail to
>> > meet
>> > > > > the release criteria, then the artifacts would be dropped from the
>> > > > staging
>> > > > > repository and never see the light of day. The tag would remain in
>> > SCM,
>> > > > > and we would document (somewhere) that the release was cancelled.
>> The
>> > > > > "respin" would have version number 3.1.1 and there would never be a
>> > > > 3.1.0.
>> > > > >
>> > > > > This change could mean that the first actual release of 3.1.x might
>> > end
>> > > > up
>> > > > > being 3.1.67 (though I personally view that as unlikely, and in the
>> > > > > context of 3.1.x I think we are very nearly there)
>> > > > >
>> > > > > Please Note:
>> > > > >
>> > > >
>> > >
>> >
>> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
>> > > > > not actually specify what it means by "the process will need to be
>> > > > > restarted" so this vote will effect a change either outcome
>> > > > >
>> > > > > +1: Never respin with the same version number, always increment the
>> > > > > version for a respin
>> > > > > 0: Don't care
>> > > > > -1: Always respin with the same version number until that version
>> > > number
>> > > > > gets released
>> > > > >
>> > > > > This vote will be open for 72 hours. A Majority of PMC votes
>> greater
>> > > that
>> > > > > 3 will be deemed as decisive in either direction (i.e. if the sum
>> is
>> > <
>> > > -3
>> > > > > or
>> > > > >> +3 then there is a documented result)
>> > > > >
>> > > > > For any releases in progress at this point in time, it is up to the
>> > > > > release manager to decide what to do if they need to do a respin.
>> > > > >
>> > > > > -Stephen
>> > > >
>> > > >
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>> > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Baptiste <Batmat> MATHUS - http://batmat.net
>> > Sauvez un arbre,
>> > Mangez un castor !
>> >
>>
>
>
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Baptiste MATHUS <bm...@batmat.net>]

You're right, my bad. I just re-read the details in Stephen's original mail.

So I'm also:
+1 for pre-releases, dropping everything to reuse numbers is not worth the
hassle
-1 for actual releases: it would create more mess imo for end users if
there's many bizarre jumps in numbering


2013/5/29 Fred Cooke <fr...@gmail.com>

> "This vote is to change the policy to:
>
> drop the staging repo, document the release as not released, and run with
> the next version."
>
> On Wed, May 29, 2013 at 9:54 PM, Baptiste MATHUS <bm...@batmat.net>
> wrote:
>
> > Well, from the wording of the VOTE question and what I've read from you
> > Fred in the past, shouldn't actually be a -1 from you here?
> >
> > What I read is "Should we respin CANCELLED releases with the same version
> > number?" then
> > +1 = current way of working, just drop the release and re-release
> (possibly
> > with "take n" in the subject mail, and so on)
> > -1 = please do not reuse number, numbers are cheap
> >
> > Was it what you intended to vote on, and was it how Stephen was thinking
> to
> > orient the sentence and the +1/-1 meaning?
> >
> >
> > 2013/5/29 Fred Cooke <fr...@gmail.com>
> >
> > > +1(million) non-binding, but if you want, I'll have your children if
> you
> > > make this extremely positive change!!!! <3
> > >
> > > On Wed, May 29, 2013 at 12:31 PM, Jörg Schaible <
> > > Joerg.Schaible@scalaris.com
> > > > wrote:
> > >
> > > > -1 (nb)
> > > >
> > > > Stephen Connolly wrote:
> > > >
> > > > > We have been using a policy of only making releases without
> skipping
> > > > > version numbers, e.g.
> > > > >
> > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > > > >
> > > > > Whereby if there is something wrong with the artifacts staged for
> > > > release,
> > > > > we drop the staging repo, delete the tag, roll back the version,
> and
> > > run
> > > > > again.
> > > > >
> > > > > This vote is to change the policy to:
> > > > >
> > > > > drop the staging repo, document the release as not released, and
> run
> > > with
> > > > > the next version.
> > > > >
> > > > > Under this new proposal, if the staged artifacts for 3.1.0 fail to
> > meet
> > > > > the release criteria, then the artifacts would be dropped from the
> > > > staging
> > > > > repository and never see the light of day. The tag would remain in
> > SCM,
> > > > > and we would document (somewhere) that the release was cancelled.
> The
> > > > > "respin" would have version number 3.1.1 and there would never be a
> > > > 3.1.0.
> > > > >
> > > > > This change could mean that the first actual release of 3.1.x might
> > end
> > > > up
> > > > > being 3.1.67 (though I personally view that as unlikely, and in the
> > > > > context of 3.1.x I think we are very nearly there)
> > > > >
> > > > > Please Note:
> > > > >
> > > >
> > >
> >
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
> > > > > not actually specify what it means by "the process will need to be
> > > > > restarted" so this vote will effect a change either outcome
> > > > >
> > > > > +1: Never respin with the same version number, always increment the
> > > > > version for a respin
> > > > > 0: Don't care
> > > > > -1: Always respin with the same version number until that version
> > > number
> > > > > gets released
> > > > >
> > > > > This vote will be open for 72 hours. A Majority of PMC votes
> greater
> > > that
> > > > > 3 will be deemed as decisive in either direction (i.e. if the sum
> is
> > <
> > > -3
> > > > > or
> > > > >> +3 then there is a documented result)
> > > > >
> > > > > For any releases in progress at this point in time, it is up to the
> > > > > release manager to decide what to do if they need to do a respin.
> > > > >
> > > > > -Stephen
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Baptiste <Batmat> MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> >
>



-- 
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Fred Cooke <fr...@gmail.com>]

"This vote is to change the policy to:

drop the staging repo, document the release as not released, and run with
the next version."

On Wed, May 29, 2013 at 9:54 PM, Baptiste MATHUS <bm...@batmat.net> wrote:

> Well, from the wording of the VOTE question and what I've read from you
> Fred in the past, shouldn't actually be a -1 from you here?
>
> What I read is "Should we respin CANCELLED releases with the same version
> number?" then
> +1 = current way of working, just drop the release and re-release (possibly
> with "take n" in the subject mail, and so on)
> -1 = please do not reuse number, numbers are cheap
>
> Was it what you intended to vote on, and was it how Stephen was thinking to
> orient the sentence and the +1/-1 meaning?
>
>
> 2013/5/29 Fred Cooke <fr...@gmail.com>
>
> > +1(million) non-binding, but if you want, I'll have your children if you
> > make this extremely positive change!!!! <3
> >
> > On Wed, May 29, 2013 at 12:31 PM, Jörg Schaible <
> > Joerg.Schaible@scalaris.com
> > > wrote:
> >
> > > -1 (nb)
> > >
> > > Stephen Connolly wrote:
> > >
> > > > We have been using a policy of only making releases without skipping
> > > > version numbers, e.g.
> > > >
> > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > > >
> > > > Whereby if there is something wrong with the artifacts staged for
> > > release,
> > > > we drop the staging repo, delete the tag, roll back the version, and
> > run
> > > > again.
> > > >
> > > > This vote is to change the policy to:
> > > >
> > > > drop the staging repo, document the release as not released, and run
> > with
> > > > the next version.
> > > >
> > > > Under this new proposal, if the staged artifacts for 3.1.0 fail to
> meet
> > > > the release criteria, then the artifacts would be dropped from the
> > > staging
> > > > repository and never see the light of day. The tag would remain in
> SCM,
> > > > and we would document (somewhere) that the release was cancelled. The
> > > > "respin" would have version number 3.1.1 and there would never be a
> > > 3.1.0.
> > > >
> > > > This change could mean that the first actual release of 3.1.x might
> end
> > > up
> > > > being 3.1.67 (though I personally view that as unlikely, and in the
> > > > context of 3.1.x I think we are very nearly there)
> > > >
> > > > Please Note:
> > > >
> > >
> >
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
> > > > not actually specify what it means by "the process will need to be
> > > > restarted" so this vote will effect a change either outcome
> > > >
> > > > +1: Never respin with the same version number, always increment the
> > > > version for a respin
> > > > 0: Don't care
> > > > -1: Always respin with the same version number until that version
> > number
> > > > gets released
> > > >
> > > > This vote will be open for 72 hours. A Majority of PMC votes greater
> > that
> > > > 3 will be deemed as decisive in either direction (i.e. if the sum is
> <
> > -3
> > > > or
> > > >> +3 then there is a documented result)
> > > >
> > > > For any releases in progress at this point in time, it is up to the
> > > > release manager to decide what to do if they need to do a respin.
> > > >
> > > > -Stephen
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Baptiste MATHUS <bm...@batmat.net>]

Well, from the wording of the VOTE question and what I've read from you
Fred in the past, shouldn't actually be a -1 from you here?

What I read is "Should we respin CANCELLED releases with the same version
number?" then
+1 = current way of working, just drop the release and re-release (possibly
with "take n" in the subject mail, and so on)
-1 = please do not reuse number, numbers are cheap

Was it what you intended to vote on, and was it how Stephen was thinking to
orient the sentence and the +1/-1 meaning?


2013/5/29 Fred Cooke <fr...@gmail.com>

> +1(million) non-binding, but if you want, I'll have your children if you
> make this extremely positive change!!!! <3
>
> On Wed, May 29, 2013 at 12:31 PM, Jörg Schaible <
> Joerg.Schaible@scalaris.com
> > wrote:
>
> > -1 (nb)
> >
> > Stephen Connolly wrote:
> >
> > > We have been using a policy of only making releases without skipping
> > > version numbers, e.g.
> > >
> > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > >
> > > Whereby if there is something wrong with the artifacts staged for
> > release,
> > > we drop the staging repo, delete the tag, roll back the version, and
> run
> > > again.
> > >
> > > This vote is to change the policy to:
> > >
> > > drop the staging repo, document the release as not released, and run
> with
> > > the next version.
> > >
> > > Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
> > > the release criteria, then the artifacts would be dropped from the
> > staging
> > > repository and never see the light of day. The tag would remain in SCM,
> > > and we would document (somewhere) that the release was cancelled. The
> > > "respin" would have version number 3.1.1 and there would never be a
> > 3.1.0.
> > >
> > > This change could mean that the first actual release of 3.1.x might end
> > up
> > > being 3.1.67 (though I personally view that as unlikely, and in the
> > > context of 3.1.x I think we are very nearly there)
> > >
> > > Please Note:
> > >
> >
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
> > > not actually specify what it means by "the process will need to be
> > > restarted" so this vote will effect a change either outcome
> > >
> > > +1: Never respin with the same version number, always increment the
> > > version for a respin
> > > 0: Don't care
> > > -1: Always respin with the same version number until that version
> number
> > > gets released
> > >
> > > This vote will be open for 72 hours. A Majority of PMC votes greater
> that
> > > 3 will be deemed as decisive in either direction (i.e. if the sum is <
> -3
> > > or
> > >> +3 then there is a documented result)
> > >
> > > For any releases in progress at this point in time, it is up to the
> > > release manager to decide what to do if they need to do a respin.
> > >
> > > -Stephen
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>



-- 
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Fred Cooke <fr...@gmail.com>]

+1(million) non-binding, but if you want, I'll have your children if you
make this extremely positive change!!!! <3

On Wed, May 29, 2013 at 12:31 PM, Jörg Schaible <Joerg.Schaible@scalaris.com
> wrote:

> -1 (nb)
>
> Stephen Connolly wrote:
>
> > We have been using a policy of only making releases without skipping
> > version numbers, e.g.
> >
> > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> >
> > Whereby if there is something wrong with the artifacts staged for
> release,
> > we drop the staging repo, delete the tag, roll back the version, and run
> > again.
> >
> > This vote is to change the policy to:
> >
> > drop the staging repo, document the release as not released, and run with
> > the next version.
> >
> > Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
> > the release criteria, then the artifacts would be dropped from the
> staging
> > repository and never see the light of day. The tag would remain in SCM,
> > and we would document (somewhere) that the release was cancelled. The
> > "respin" would have version number 3.1.1 and there would never be a
> 3.1.0.
> >
> > This change could mean that the first actual release of 3.1.x might end
> up
> > being 3.1.67 (though I personally view that as unlikely, and in the
> > context of 3.1.x I think we are very nearly there)
> >
> > Please Note:
> >
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
> > not actually specify what it means by "the process will need to be
> > restarted" so this vote will effect a change either outcome
> >
> > +1: Never respin with the same version number, always increment the
> > version for a respin
> > 0: Don't care
> > -1: Always respin with the same version number until that version number
> > gets released
> >
> > This vote will be open for 72 hours. A Majority of PMC votes greater that
> > 3 will be deemed as decisive in either direction (i.e. if the sum is < -3
> > or
> >> +3 then there is a documented result)
> >
> > For any releases in progress at this point in time, it is up to the
> > release manager to decide what to do if they need to do a respin.
> >
> > -Stephen
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Jörg Schaible <Jo...@scalaris.com>]

-1 (nb)

Stephen Connolly wrote:

> We have been using a policy of only making releases without skipping
> version numbers, e.g.
> 
> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> 
> Whereby if there is something wrong with the artifacts staged for release,
> we drop the staging repo, delete the tag, roll back the version, and run
> again.
> 
> This vote is to change the policy to:
> 
> drop the staging repo, document the release as not released, and run with
> the next version.
> 
> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
> the release criteria, then the artifacts would be dropped from the staging
> repository and never see the light of day. The tag would remain in SCM,
> and we would document (somewhere) that the release was cancelled. The
> "respin" would have version number 3.1.1 and there would never be a 3.1.0.
> 
> This change could mean that the first actual release of 3.1.x might end up
> being 3.1.67 (though I personally view that as unlikely, and in the
> context of 3.1.x I think we are very nearly there)
> 
> Please Note:
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
> not actually specify what it means by "the process will need to be
> restarted" so this vote will effect a change either outcome
> 
> +1: Never respin with the same version number, always increment the
> version for a respin
> 0: Don't care
> -1: Always respin with the same version number until that version number
> gets released
> 
> This vote will be open for 72 hours. A Majority of PMC votes greater that
> 3 will be deemed as decisive in either direction (i.e. if the sum is < -3
> or
>> +3 then there is a documented result)
> 
> For any releases in progress at this point in time, it is up to the
> release manager to decide what to do if they need to do a respin.
> 
> -Stephen



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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Gary Gregory <ga...@gmail.com>]

-1 non-binding, this is confusing. That's what RC tags are for.

Gary

On Jun 2, 2013, at 11:54, Benson Margulies <bi...@gmail.com> wrote:

> -1 binding to changing to burning versions.
>
> On Sun, Jun 2, 2013 at 10:56 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>> -1 (binding)
>>
>> Ralph
>> On May 29, 2013, at 3:01 AM, Stephen Connolly wrote:
>>
>>> We have been using a policy of only making releases without skipping
>>> version numbers, e.g.
>>>
>>> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>>>
>>> Whereby if there is something wrong with the artifacts staged for release,
>>> we drop the staging repo, delete the tag, roll back the version, and run
>>> again.
>>>
>>> This vote is to change the policy to:
>>>
>>> drop the staging repo, document the release as not released, and run with
>>> the next version.
>>>
>>> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the
>>> release criteria, then the artifacts would be dropped from the staging
>>> repository and never see the light of day. The tag would remain in SCM, and
>>> we would document (somewhere) that the release was cancelled. The "respin"
>>> would have version number 3.1.1 and there would never be a 3.1.0.
>>>
>>> This change could mean that the first actual release of 3.1.x might end up
>>> being 3.1.67 (though I personally view that as unlikely, and in the context
>>> of 3.1.x I think we are very nearly there)
>>>
>>> Please Note:
>>> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
>>> not actually specify what it means by "the process will need to be
>>> restarted" so this vote will effect a change either outcome
>>>
>>> +1: Never respin with the same version number, always increment the version
>>> for a respin
>>> 0: Don't care
>>> -1: Always respin with the same version number until that version number
>>> gets released
>>>
>>> This vote will be open for 72 hours. A Majority of PMC votes greater that 3
>>> will be deemed as decisive in either direction (i.e. if the sum is < -3 or
>>>> +3 then there is a documented result)
>>>
>>> For any releases in progress at this point in time, it is up to the release
>>> manager to decide what to do if they need to do a respin.
>>>
>>> -Stephen
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Benson Margulies <bi...@gmail.com>]

-1 binding to changing to burning versions.

On Sun, Jun 2, 2013 at 10:56 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> -1 (binding)
>
> Ralph
> On May 29, 2013, at 3:01 AM, Stephen Connolly wrote:
>
>> We have been using a policy of only making releases without skipping
>> version numbers, e.g.
>>
>> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>>
>> Whereby if there is something wrong with the artifacts staged for release,
>> we drop the staging repo, delete the tag, roll back the version, and run
>> again.
>>
>> This vote is to change the policy to:
>>
>> drop the staging repo, document the release as not released, and run with
>> the next version.
>>
>> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the
>> release criteria, then the artifacts would be dropped from the staging
>> repository and never see the light of day. The tag would remain in SCM, and
>> we would document (somewhere) that the release was cancelled. The "respin"
>> would have version number 3.1.1 and there would never be a 3.1.0.
>>
>> This change could mean that the first actual release of 3.1.x might end up
>> being 3.1.67 (though I personally view that as unlikely, and in the context
>> of 3.1.x I think we are very nearly there)
>>
>> Please Note:
>> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
>> not actually specify what it means by "the process will need to be
>> restarted" so this vote will effect a change either outcome
>>
>> +1: Never respin with the same version number, always increment the version
>> for a respin
>> 0: Don't care
>> -1: Always respin with the same version number until that version number
>> gets released
>>
>> This vote will be open for 72 hours. A Majority of PMC votes greater that 3
>> will be deemed as decisive in either direction (i.e. if the sum is < -3 or
>>> +3 then there is a documented result)
>>
>> For any releases in progress at this point in time, it is up to the release
>> manager to decide what to do if they need to do a respin.
>>
>> -Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Ralph Goers <ra...@dslextreme.com>]

-1 (binding)

Ralph
On May 29, 2013, at 3:01 AM, Stephen Connolly wrote:

> We have been using a policy of only making releases without skipping
> version numbers, e.g.
> 
> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> 
> Whereby if there is something wrong with the artifacts staged for release,
> we drop the staging repo, delete the tag, roll back the version, and run
> again.
> 
> This vote is to change the policy to:
> 
> drop the staging repo, document the release as not released, and run with
> the next version.
> 
> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the
> release criteria, then the artifacts would be dropped from the staging
> repository and never see the light of day. The tag would remain in SCM, and
> we would document (somewhere) that the release was cancelled. The "respin"
> would have version number 3.1.1 and there would never be a 3.1.0.
> 
> This change could mean that the first actual release of 3.1.x might end up
> being 3.1.67 (though I personally view that as unlikely, and in the context
> of 3.1.x I think we are very nearly there)
> 
> Please Note:
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
> not actually specify what it means by "the process will need to be
> restarted" so this vote will effect a change either outcome
> 
> +1: Never respin with the same version number, always increment the version
> for a respin
> 0: Don't care
> -1: Always respin with the same version number until that version number
> gets released
> 
> This vote will be open for 72 hours. A Majority of PMC votes greater that 3
> will be deemed as decisive in either direction (i.e. if the sum is < -3 or
>> +3 then there is a documented result)
> 
> For any releases in progress at this point in time, it is up to the release
> manager to decide what to do if they need to do a respin.
> 
> -Stephen


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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Anders Hammar <an...@hammar.net>]

+1 for pre-releases (RC, etc)
-1 for actual releases
(non-binding)

/Anders


On Thu, May 30, 2013 at 8:20 AM, Hervé BOUTEMY <he...@free.fr>wrote:

> I agree with Dan and Wayne
>
> +1 for "qualified" releases (alpha, beta, RC, etc…) that are working
> toward the
> full blow release but aren't intended to be that.
>
> -1 for the actual releases.
>
> And I don't care if the next 3.1.0-alpha is alpha-2 or alpha-4: what I
> care is
> that it is not alpha-1 any more since we're getting confused (votes, git
> tag
> copied in local copy)
>
> Regards,
>
> Hervé
>
> Le mercredi 29 mai 2013 14:52:45 Wayne Fay a écrit :
> > Agree with Dan.
> > +1 for qualified
> > -1 for actual
> >
> > Wayne
> >
> > On Wed, May 29, 2013 at 8:20 AM, Daniel Kulp <dk...@apache.org> wrote:
> > > +1 for "qualified" releases (alpha, beta, RC, etc…) that are working
> > > toward the full blow release but aren't intended to be that.
> > >
> > > -1 for the actual releases.
> > >
> > > Dan
> > >
> > > On May 29, 2013, at 6:01 AM, Stephen Connolly
> <st...@gmail.com> wrote:
> > >> We have been using a policy of only making releases without skipping
> > >> version numbers, e.g.
> > >>
> > >> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> > >>
> > >> Whereby if there is something wrong with the artifacts staged for
> > >> release,
> > >> we drop the staging repo, delete the tag, roll back the version, and
> run
> > >> again.
> > >>
> > >> This vote is to change the policy to:
> > >>
> > >> drop the staging repo, document the release as not released, and run
> with
> > >> the next version.
> > >>
> > >> Under this new proposal, if the staged artifacts for 3.1.0 fail to
> meet
> > >> the
> > >> release criteria, then the artifacts would be dropped from the staging
> > >> repository and never see the light of day. The tag would remain in
> SCM,
> > >> and
> > >> we would document (somewhere) that the release was cancelled. The
> > >> "respin"
> > >> would have version number 3.1.1 and there would never be a 3.1.0.
> > >>
> > >> This change could mean that the first actual release of 3.1.x might
> end
> > >> up
> > >> being 3.1.67 (though I personally view that as unlikely, and in the
> > >> context
> > >> of 3.1.x I think we are very nearly there)
> > >>
> > >> Please Note:
> > >>
> http://maven.apache.org/developers/release/maven-project-release-procedur
> > >> e.html#Check_the_vote_resultsdoes not actually specify what it means
> by
> > >> "the process will need to be restarted" so this vote will effect a
> > >> change either outcome
> > >>
> > >> +1: Never respin with the same version number, always increment the
> > >> version
> > >> for a respin
> > >> 0: Don't care
> > >> -1: Always respin with the same version number until that version
> number
> > >> gets released
> > >>
> > >> This vote will be open for 72 hours. A Majority of PMC votes greater
> that
> > >> 3
> > >> will be deemed as decisive in either direction (i.e. if the sum is <
> -3
> > >> or
> > >>
> > >>> +3 then there is a documented result)
> > >>
> > >> For any releases in progress at this point in time, it is up to the
> > >> release
> > >> manager to decide what to do if they need to do a respin.
> > >>
> > >> -Stephen
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org - http://dankulp.com/blog
> > > Talend Community Coder - http://coders.talend.com
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Hervé BOUTEMY <he...@free.fr>]

I agree with Dan and Wayne

+1 for "qualified" releases (alpha, beta, RC, etc…) that are working toward the 
full blow release but aren't intended to be that.

-1 for the actual releases.

And I don't care if the next 3.1.0-alpha is alpha-2 or alpha-4: what I care is 
that it is not alpha-1 any more since we're getting confused (votes, git tag 
copied in local copy)

Regards,

Hervé

Le mercredi 29 mai 2013 14:52:45 Wayne Fay a écrit :
> Agree with Dan.
> +1 for qualified
> -1 for actual
> 
> Wayne
> 
> On Wed, May 29, 2013 at 8:20 AM, Daniel Kulp <dk...@apache.org> wrote:
> > +1 for "qualified" releases (alpha, beta, RC, etc…) that are working
> > toward the full blow release but aren't intended to be that.
> > 
> > -1 for the actual releases.
> > 
> > Dan
> > 
> > On May 29, 2013, at 6:01 AM, Stephen Connolly 
<st...@gmail.com> wrote:
> >> We have been using a policy of only making releases without skipping
> >> version numbers, e.g.
> >> 
> >> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> >> 
> >> Whereby if there is something wrong with the artifacts staged for
> >> release,
> >> we drop the staging repo, delete the tag, roll back the version, and run
> >> again.
> >> 
> >> This vote is to change the policy to:
> >> 
> >> drop the staging repo, document the release as not released, and run with
> >> the next version.
> >> 
> >> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
> >> the
> >> release criteria, then the artifacts would be dropped from the staging
> >> repository and never see the light of day. The tag would remain in SCM,
> >> and
> >> we would document (somewhere) that the release was cancelled. The
> >> "respin"
> >> would have version number 3.1.1 and there would never be a 3.1.0.
> >> 
> >> This change could mean that the first actual release of 3.1.x might end
> >> up
> >> being 3.1.67 (though I personally view that as unlikely, and in the
> >> context
> >> of 3.1.x I think we are very nearly there)
> >> 
> >> Please Note:
> >> http://maven.apache.org/developers/release/maven-project-release-procedur
> >> e.html#Check_the_vote_resultsdoes not actually specify what it means by
> >> "the process will need to be restarted" so this vote will effect a
> >> change either outcome
> >> 
> >> +1: Never respin with the same version number, always increment the
> >> version
> >> for a respin
> >> 0: Don't care
> >> -1: Always respin with the same version number until that version number
> >> gets released
> >> 
> >> This vote will be open for 72 hours. A Majority of PMC votes greater that
> >> 3
> >> will be deemed as decisive in either direction (i.e. if the sum is < -3
> >> or
> >> 
> >>> +3 then there is a documented result)
> >> 
> >> For any releases in progress at this point in time, it is up to the
> >> release
> >> manager to decide what to do if they need to do a respin.
> >> 
> >> -Stephen
> > 
> > --
> > Daniel Kulp
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Wayne Fay <wa...@gmail.com>]

Agree with Dan.
+1 for qualified
-1 for actual

Wayne

On Wed, May 29, 2013 at 8:20 AM, Daniel Kulp <dk...@apache.org> wrote:
> +1 for "qualified" releases (alpha, beta, RC, etc…) that are working toward the full blow release but aren't intended to be that.
>
> -1 for the actual releases.
>
> Dan
>
>
>
> On May 29, 2013, at 6:01 AM, Stephen Connolly <st...@gmail.com> wrote:
>
>> We have been using a policy of only making releases without skipping
>> version numbers, e.g.
>>
>> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>>
>> Whereby if there is something wrong with the artifacts staged for release,
>> we drop the staging repo, delete the tag, roll back the version, and run
>> again.
>>
>> This vote is to change the policy to:
>>
>> drop the staging repo, document the release as not released, and run with
>> the next version.
>>
>> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the
>> release criteria, then the artifacts would be dropped from the staging
>> repository and never see the light of day. The tag would remain in SCM, and
>> we would document (somewhere) that the release was cancelled. The "respin"
>> would have version number 3.1.1 and there would never be a 3.1.0.
>>
>> This change could mean that the first actual release of 3.1.x might end up
>> being 3.1.67 (though I personally view that as unlikely, and in the context
>> of 3.1.x I think we are very nearly there)
>>
>> Please Note:
>> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
>> not actually specify what it means by "the process will need to be
>> restarted" so this vote will effect a change either outcome
>>
>> +1: Never respin with the same version number, always increment the version
>> for a respin
>> 0: Don't care
>> -1: Always respin with the same version number until that version number
>> gets released
>>
>> This vote will be open for 72 hours. A Majority of PMC votes greater that 3
>> will be deemed as decisive in either direction (i.e. if the sum is < -3 or
>>> +3 then there is a documented result)
>>
>> For any releases in progress at this point in time, it is up to the release
>> manager to decide what to do if they need to do a respin.
>>
>> -Stephen
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Stephen Connolly <st...@gmail.com>]

I will be counting spilt votes like this as the actual release vote... If
we want to finesse for alpha and beta after the principle for releases is
established, we can have another vote...

So to clarify: Robert's vote is currently

-1 reuse version numbers when respinning

On Thursday, 30 May 2013, Robert Scholte wrote:

> Let me rephrase my vote:
>
> +1 for qualified releases
>
> -1 for actual releases
>
> Robert
>
> Op Wed, 29 May 2013 19:07:59 +0200 schreef Robert Scholte <
> rfscholte@apache.org>:
>
>  -1 (binding) on actual releases
>>
>> Robert
>>
>>
>> Op Wed, 29 May 2013 15:20:17 +0200 schreef Daniel Kulp <dkulp@apache.org
>> >:
>>
>>  +1 for "qualified" releases (alpha, beta, RC, etc…) that are working
>>> toward the full blow release but aren't intended to be that.
>>>
>>> -1 for the actual releases.
>>>
>>> Dan
>>>
>>>
>>>
>>> On May 29, 2013, at 6:01 AM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>  We have been using a policy of only making releases without skipping
>>>> version numbers, e.g.
>>>>
>>>> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>>>>
>>>> Whereby if there is something wrong with the artifacts staged for
>>>> release,
>>>> we drop the staging repo, delete the tag, roll back the version, and run
>>>> again.
>>>>
>>>> This vote is to change the policy to:
>>>>
>>>> drop the staging repo, document the release as not released, and run
>>>> with
>>>> the next version.
>>>>
>>>> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
>>>> the
>>>> release criteria, then the artifacts would be dropped from the staging
>>>> repository and never see the light of day. The tag would remain in SCM,
>>>> and
>>>> we would document (somewhere) that the release was cancelled. The
>>>> "respin"
>>>> would have version number 3.1.1 and there would never be a 3.1.0.
>>>>
>>>> This change could mean that the first actual release of 3.1.x might end
>>>> up
>>>> being 3.1.67 (though I personally view that as unlikely, and in the
>>>> context
>>>> of 3.1.x I think we are very nearly there)
>>>>
>>>> Please Note:
>>>> http://maven.apache.org/**developers/release/maven-**
>>>> project-release-procedure.**html#Check_the_vote_**resultsdoes<http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes>
>>>> not actually specify what it means by "the process will need to be
>>>> restarted" so this vote will effect a change either outcome
>>>>
>>>> +1: Never respin with the same version number, always increment the
>>>> version
>>>> for a respin
>>>> 0: Don't care
>>>> -1: Always respin with the same version number until that version number
>>>> gets released
>>>>
>>>> This vote will be open for 72 hours. A Majority of PMC votes greater
>>>> that 3
>>>> will be deemed as decisive in either direction (i.e. if the sum is < -3
>>>> or
>>>>
>>>>> +3 then there is a documented result)
>>>>>
>>>>
>>>> For any releases in progress at this point in time, it is up to the
>>>> release
>>>> manager to decide what to do if they need to do a respin.
>>>>
>>>> -Stephen
>>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

-- 
Sent from my phone

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Robert Scholte <rf...@apache.org>]

Let me rephrase my vote:

+1 for qualified releases

-1 for actual releases

Robert

Op Wed, 29 May 2013 19:07:59 +0200 schreef Robert Scholte  
<rf...@apache.org>:

> -1 (binding) on actual releases
>
> Robert
>
>
> Op Wed, 29 May 2013 15:20:17 +0200 schreef Daniel Kulp  
> <dk...@apache.org>:
>
>> +1 for "qualified" releases (alpha, beta, RC, etc…) that are working  
>> toward the full blow release but aren't intended to be that.
>>
>> -1 for the actual releases.
>>
>> Dan
>>
>>
>>
>> On May 29, 2013, at 6:01 AM, Stephen Connolly  
>> <st...@gmail.com> wrote:
>>
>>> We have been using a policy of only making releases without skipping
>>> version numbers, e.g.
>>>
>>> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>>>
>>> Whereby if there is something wrong with the artifacts staged for  
>>> release,
>>> we drop the staging repo, delete the tag, roll back the version, and  
>>> run
>>> again.
>>>
>>> This vote is to change the policy to:
>>>
>>> drop the staging repo, document the release as not released, and run  
>>> with
>>> the next version.
>>>
>>> Under this new proposal, if the staged artifacts for 3.1.0 fail to  
>>> meet the
>>> release criteria, then the artifacts would be dropped from the staging
>>> repository and never see the light of day. The tag would remain in  
>>> SCM, and
>>> we would document (somewhere) that the release was cancelled. The  
>>> "respin"
>>> would have version number 3.1.1 and there would never be a 3.1.0.
>>>
>>> This change could mean that the first actual release of 3.1.x might  
>>> end up
>>> being 3.1.67 (though I personally view that as unlikely, and in the  
>>> context
>>> of 3.1.x I think we are very nearly there)
>>>
>>> Please Note:
>>> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
>>> not actually specify what it means by "the process will need to be
>>> restarted" so this vote will effect a change either outcome
>>>
>>> +1: Never respin with the same version number, always increment the  
>>> version
>>> for a respin
>>> 0: Don't care
>>> -1: Always respin with the same version number until that version  
>>> number
>>> gets released
>>>
>>> This vote will be open for 72 hours. A Majority of PMC votes greater  
>>> that 3
>>> will be deemed as decisive in either direction (i.e. if the sum is <  
>>> -3 or
>>>> +3 then there is a documented result)
>>>
>>> For any releases in progress at this point in time, it is up to the  
>>> release
>>> manager to decide what to do if they need to do a respin.
>>>
>>> -Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Robert Scholte <rf...@apache.org>]

-1 (binding) on actual releases

Robert


Op Wed, 29 May 2013 15:20:17 +0200 schreef Daniel Kulp <dk...@apache.org>:

> +1 for "qualified" releases (alpha, beta, RC, etc…) that are working  
> toward the full blow release but aren't intended to be that.
>
> -1 for the actual releases.
>
> Dan
>
>
>
> On May 29, 2013, at 6:01 AM, Stephen Connolly  
> <st...@gmail.com> wrote:
>
>> We have been using a policy of only making releases without skipping
>> version numbers, e.g.
>>
>> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
>>
>> Whereby if there is something wrong with the artifacts staged for  
>> release,
>> we drop the staging repo, delete the tag, roll back the version, and run
>> again.
>>
>> This vote is to change the policy to:
>>
>> drop the staging repo, document the release as not released, and run  
>> with
>> the next version.
>>
>> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet  
>> the
>> release criteria, then the artifacts would be dropped from the staging
>> repository and never see the light of day. The tag would remain in SCM,  
>> and
>> we would document (somewhere) that the release was cancelled. The  
>> "respin"
>> would have version number 3.1.1 and there would never be a 3.1.0.
>>
>> This change could mean that the first actual release of 3.1.x might end  
>> up
>> being 3.1.67 (though I personally view that as unlikely, and in the  
>> context
>> of 3.1.x I think we are very nearly there)
>>
>> Please Note:
>> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
>> not actually specify what it means by "the process will need to be
>> restarted" so this vote will effect a change either outcome
>>
>> +1: Never respin with the same version number, always increment the  
>> version
>> for a respin
>> 0: Don't care
>> -1: Always respin with the same version number until that version number
>> gets released
>>
>> This vote will be open for 72 hours. A Majority of PMC votes greater  
>> that 3
>> will be deemed as decisive in either direction (i.e. if the sum is < -3  
>> or
>>> +3 then there is a documented result)
>>
>> For any releases in progress at this point in time, it is up to the  
>> release
>> manager to decide what to do if they need to do a respin.
>>
>> -Stephen

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Daniel Kulp <dk...@apache.org>]

+1 for "qualified" releases (alpha, beta, RC, etc…) that are working toward the full blow release but aren't intended to be that.

-1 for the actual releases.

Dan



On May 29, 2013, at 6:01 AM, Stephen Connolly <st...@gmail.com> wrote:

> We have been using a policy of only making releases without skipping
> version numbers, e.g.
> 
> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
> 
> Whereby if there is something wrong with the artifacts staged for release,
> we drop the staging repo, delete the tag, roll back the version, and run
> again.
> 
> This vote is to change the policy to:
> 
> drop the staging repo, document the release as not released, and run with
> the next version.
> 
> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the
> release criteria, then the artifacts would be dropped from the staging
> repository and never see the light of day. The tag would remain in SCM, and
> we would document (somewhere) that the release was cancelled. The "respin"
> would have version number 3.1.1 and there would never be a 3.1.0.
> 
> This change could mean that the first actual release of 3.1.x might end up
> being 3.1.67 (though I personally view that as unlikely, and in the context
> of 3.1.x I think we are very nearly there)
> 
> Please Note:
> http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
> not actually specify what it means by "the process will need to be
> restarted" so this vote will effect a change either outcome
> 
> +1: Never respin with the same version number, always increment the version
> for a respin
> 0: Don't care
> -1: Always respin with the same version number until that version number
> gets released
> 
> This vote will be open for 72 hours. A Majority of PMC votes greater that 3
> will be deemed as decisive in either direction (i.e. if the sum is < -3 or
>> +3 then there is a documented result)
> 
> For any releases in progress at this point in time, it is up to the release
> manager to decide what to do if they need to do a respin.
> 
> -Stephen

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


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