date:20130529

Sorry, but Maven sandbox is write protected for me.

I created a svn patch file but I don't know where to fill the issue
(project, component in jira).

Regards,

Eric

-Message d'origine-
De : Hervé BOUTEMY [mailto:herve.bout...@free.fr] 
Envoyé : mardi 28 mai 2013 22:44
À : Maven Developers List
Objet : Re: CALL TO CONTRIBUTION: dist tooling

great!
thanks for your help

yes, a maven plugin can be a solution, even if report is overkill IMHO: we
won't publish result

Maven sandbox [1] should be writeable to any Apache committer, IIUC

Regards,

Hervé

[1] https://svn.apache.org/repos/asf/maven/sandbox/trunk/

Le mardi 28 mai 2013 17:54:31 Eric Barboni a écrit :
> Hi,
> 
>   If still open, I'm interested to help on this part.
> 
>  Can it be a maven plugin with html report (A bit overkill maybe but
scripts
> on windows are annoying)   ?
> 
> Where should the tool be located in the scm tree (to facilitate patch
> creation) ?
> 
>  Regards,
> 
> Eric
> 
> -Message d'origine-
> De : Hervé BOUTEMY [mailto:herve.bout...@free.fr] Envoyé : mercredi 24 
> avril 2013 13:23 À : Maven Developers List Objet : CALL TO 
> CONTRIBUTION: dist tooling
> 
> I just did some checks in our distribution area [1] and found a good 
> number of missing releases In addition to asking committers to 
> remember our procedure [2] (and ask for PMC help if necessary) , I 
> just thought it would be good to have a little tool to check against
latest artifact releases:
> with a little config file giving groupId:artifactId and directory in 
> dist, it could check if latest version from central metadata [3] is 
> actually published in dist and warn if not.
> 
> This is a first step, since a lot more help can be added later, I have 
> a good number of ideas (download the new release, propose svn commands 
> to remove old releases and add new ones, check consistency with site, 
> ...)
> 
> But I don't want to code it right now and prefer concentrate working 
> on
> maven- site-plugin, dependency:tree and so on related le future Maven 
> version.
> 
> I thought this could be a good opportunity for someone to do somthing 
> without having to learn too much on existing code.
> 
> Is there anybody interested?
> 
> Regards,
> 
> Hervé
> 
> 
> [1] https://dist.apache.org/repos/dist/release/maven/
> 
> [2] http://maven.apache.org/developers/release/maven-project-release-> 
> procedure.html#Copy_the_source_release_to_the_Apache_Distribution_Area
> 
> [3] 
> http://repo.maven.apache.org/maven2/org/apache/maven/reporting/maven-> 
> reporting-exec/maven-metadata.xml
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For 
> additional commands, e-mail: dev-h...@maven.apache.org

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



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

Re: [VOTE] Apache 3.1.0-alpha-1

On Wed, May 29, 2013 at 7:39 AM, Hervé BOUTEMY wrote:

> good idea: can you open a Jira issue?
>

Done :  https://jira.codehaus.org/browse/MNG-5482
Another probably more stupid idea : Wasn't it possible to use the shade
plugin or something like this to provide a version of aether under the old
groupId to not have such requirement in plugins upgrades ? Something that
we'll have been able to remove in a next major release (4)

Good news, about Aether I perhaps found an improvement in its performances
: https://gist.github.com/aheritier/5668330
It's interesting for me but won't be so impressive for 99,99% of projects
where the dependency resolution time is really reduced compared to others
tasks (compilation, tests ..)

Bad news I also found a bug : https://jira.codehaus.org/browse/MNG-5483

Cheers,




> notice, at a first pass, improving content of
> http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerExceptionto
> explain the special case of Aether is easy. But I'll try to have a
> dedicated
> link tonight: I know that the code will go in DefaultExceptionHandler
> class in
> maven-core, my only hesitation actually is how to code ITs to test the
> result:
> are there already ITs checking such error messages?
>
> Regards,
>
> Hervé
>
> Le mardi 28 mai 2013 18:31:26 Arnaud Héritier a écrit :
> > For now I had no issue with this release after an upgrade of few plugins
> >
> > In the future (another Alpha ..) couldn't you catch such error and
> provide
> > a more user friendly message asking to upgrade the plugin :
> >
> > [INFO] Dependency-reduced POM written at:
> >
> /Users/arnaud/Code/eXo/platform-public-distributions/plf-tomcat-extensions-m
> > anager/dependency-reduced-pom.xml [WARNING] Error injecting:
> >
> org.apache.maven.shared.dependency.graph.internal.Maven3DependencyGraphBuild
> > er java.lang.NoClassDefFoundError: org/sonatype/aether/graph/Dependency
> at
> > java.lang.Class.getDeclaredMethods0(Native Method)
> > at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
> >  at java.lang.Class.getDeclaredMethods(Class.java:1793)
> > at
> >
> com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:
> > 674) at
> >
> com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPo
> > int.java:366) at
> >
> com.google.inject.internal.ConstructorBindingImpl.getInternalDependencies(Co
> > nstructorBindingImpl.java:165) at
> >
> com.google.inject.internal.InjectorImpl.getInternalDependencies(InjectorImpl
> > .java:609) at
> > com.google.inject.internal.InjectorImpl.cleanup(InjectorImpl.java:565) at
> >
> com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.ja
> > va:551) at
> >
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl
> > .java:865) at
> >
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(Inj
> > ectorImpl.java:790) at
> >
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.ja
> > va:278) at
> >
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:
> > 210) at
> >
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java
> > :986) at
> >
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
> > at
> >
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
> >  at
> >
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
> > at
> >
> org.eclipse.sisu.reflect.AbstractDeferredClass.get(AbstractDeferredClass.jav
> > a:44) at
> >
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInterna
> > lFactory.java:86) at
> >
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(I
> > nternalFactoryToInitializableAdapter.java:55) at
> >
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFa
> > ctory.java:70) at
> >
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provisio
> > n(ProvisionListenerStackCallback.java:100) at
> >
> org.eclipse.sisu.plexus.lifecycles.PlexusLifecycleManager.onProvision(Plexus
> > LifecycleManager.java:134) at
> >
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provisio
> > n(ProvisionListenerStackCallback.java:109) at
> >
> com.google.inject.internal.ProvisionListenerStackCallback.provision(Provisio
> > nListenerStackCallback.java:55) at
> >
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInter
> > nalFactory.java:68) at
> >
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(Interna
> > lFactoryToInitializableAdapter.java:47) at
> >
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderT
> > oInternalFactoryAdapter.java:46) at
> >
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054
> > ) at
> >
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToIn
> > ternalFactoryAdapter.java:40) at
> > com.goog

Re: [VOTE] Apache 3.1.0-alpha-1

2013-05-29 Thread Jörg Schaible

Arnaud Héritier wrote:

> On Wed, May 29, 2013 at 7:39 AM, Hervé BOUTEMY
> wrote:
> 
>> good idea: can you open a Jira issue?
>>
> 
> Done :  https://jira.codehaus.org/browse/MNG-5482
> Another probably more stupid idea : Wasn't it possible to use the shade
> plugin or something like this to provide a version of aether under the old
> groupId to not have such requirement in plugins upgrades ? Something that
> we'll have been able to remove in a next major release (4)

Weird idea: A ClassLoader that exchanges the package name automatically, 
along with a fat deprecation warning?

- Jörg


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

Re: [VOTE] Apache 3.1.0-alpha-1

There were method signature changes as well, so its not just a package
rename IIRC


On 29 May 2013 08:57, Jörg Schaible  wrote:

> Arnaud Héritier wrote:
>
> > On Wed, May 29, 2013 at 7:39 AM, Hervé BOUTEMY
> > wrote:
> >
> >> good idea: can you open a Jira issue?
> >>
> >
> > Done :  https://jira.codehaus.org/browse/MNG-5482
> > Another probably more stupid idea : Wasn't it possible to use the shade
> > plugin or something like this to provide a version of aether under the
> old
> > groupId to not have such requirement in plugins upgrades ? Something that
> > we'll have been able to remove in a next major release (4)
>
> Weird idea: A ClassLoader that exchanges the package name automatically,
> along with a fat deprecation warning?
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Apache 3.1.0-alpha-1

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

> There were method signature changes as well, so its not just a package
> rename IIRC
>

Ok that explains it
I remember there were some threads about it but I didn't read all of them.




>
>
> On 29 May 2013 08:57, Jörg Schaible  wrote:
>
> > Arnaud Héritier wrote:
> >
> > > On Wed, May 29, 2013 at 7:39 AM, Hervé BOUTEMY
> > > wrote:
> > >
> > >> good idea: can you open a Jira issue?
> > >>
> > >
> > > Done :  https://jira.codehaus.org/browse/MNG-5482
> > > Another probably more stupid idea : Wasn't it possible to use the shade
> > > plugin or something like this to provide a version of aether under the
> > old
> > > groupId to not have such requirement in plugins upgrades ? Something
> that
> > > we'll have been able to remove in a next major release (4)
> >
> > Weird idea: A ClassLoader that exchanges the package name automatically,
> > along with a fat deprecation warning?
> >
> > - Jörg
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>



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

Re: CALL TO CONTRIBUTION: dist tooling

2013-05-29 Thread Olivier Lamy

weird.
what is the error message ? and svn url you are using ?

2013/5/29 Eric Barboni :
> Sorry, but Maven sandbox is write protected for me.
>
> I created a svn patch file but I don't know where to fill the issue
> (project, component in jira).
>
> Regards,
>
> Eric
>
> -Message d'origine-
> De : Hervé BOUTEMY [mailto:herve.bout...@free.fr]
> Envoyé : mardi 28 mai 2013 22:44
> À : Maven Developers List
> Objet : Re: CALL TO CONTRIBUTION: dist tooling
>
> great!
> thanks for your help
>
> yes, a maven plugin can be a solution, even if report is overkill IMHO: we
> won't publish result
>
> Maven sandbox [1] should be writeable to any Apache committer, IIUC
>
> Regards,
>
> Hervé
>
> [1] https://svn.apache.org/repos/asf/maven/sandbox/trunk/
>
> Le mardi 28 mai 2013 17:54:31 Eric Barboni a écrit :
>> Hi,
>>
>>   If still open, I'm interested to help on this part.
>>
>>  Can it be a maven plugin with html report (A bit overkill maybe but
> scripts
>> on windows are annoying)   ?
>>
>> Where should the tool be located in the scm tree (to facilitate patch
>> creation) ?
>>
>>  Regards,
>>
>> Eric
>>
>> -Message d'origine-
>> De : Hervé BOUTEMY [mailto:herve.bout...@free.fr] Envoyé : mercredi 24
>> avril 2013 13:23 À : Maven Developers List Objet : CALL TO
>> CONTRIBUTION: dist tooling
>>
>> I just did some checks in our distribution area [1] and found a good
>> number of missing releases In addition to asking committers to
>> remember our procedure [2] (and ask for PMC help if necessary) , I
>> just thought it would be good to have a little tool to check against
> latest artifact releases:
>> with a little config file giving groupId:artifactId and directory in
>> dist, it could check if latest version from central metadata [3] is
>> actually published in dist and warn if not.
>>
>> This is a first step, since a lot more help can be added later, I have
>> a good number of ideas (download the new release, propose svn commands
>> to remove old releases and add new ones, check consistency with site,
>> ...)
>>
>> But I don't want to code it right now and prefer concentrate working
>> on
>> maven- site-plugin, dependency:tree and so on related le future Maven
>> version.
>>
>> I thought this could be a good opportunity for someone to do somthing
>> without having to learn too much on existing code.
>>
>> Is there anybody interested?
>>
>> Regards,
>>
>> Hervé
>>
>>
>> [1] https://dist.apache.org/repos/dist/release/maven/
>>
>> [2] http://maven.apache.org/developers/release/maven-project-release->
>> procedure.html#Copy_the_source_release_to_the_Apache_Distribution_Area
>>
>> [3]
>> http://repo.maven.apache.org/maven2/org/apache/maven/reporting/maven->
>> reporting-exec/maven-metadata.xml
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
>> additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional
> commands, e-mail: dev-h...@maven.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

Re: [VOTE] Apache 3.1.0-alpha-1

On 29 May 2013 06:49, jieryn  wrote:

> Greetings,
>
> On Wed, May 29, 2013 at 1:36 AM, Hervé BOUTEMY 
> wrote:
> > I'd like to work on Arnaud's idea of error message enhancement in case a
> > plugin fails because of unavailable Sonatype Aether: if you can let me
> 12 more
> > hours from now, I'll do it tonight
>
> Version numbers are cheap. Can't we just make an alpha-2?
>
> I'm just a user, but I'm getting pretty sick of staged alpha releases
> being dropped.
>
> This happened with 3.0.5 as well. Just release it already. They are
> alphas. Christ.
>

Well for the NOTICE.txt issue, we cannot actually make a release for legal
reasons without
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=b0a83f62
being
part of the release.

The question is whether it is better to have the first 3.1.0 alpha release
be called 3.1.0-alpha-4 or 3.1.0-alpha-1

When people come back and look at the git history, they will see the
commits with "[maven-release] Prepare 3.1.0-alpha-1" through to
"[maven-release] Prepare 3.1.0-alpha-4" but only see the tag for
maven-3.1.0-alpha-4 and they might incorrectly assume that somebody just
forgot to push the tag (similarly they could undelete the SVN tag, so this
is not a GIT thing) and then you could end up with a situation where the
ASF is sued for making a release of Maven without attributing the Eclipse
foundation correctly...

Yes, I know that specific example is unlikely, but the point is that there
is potential for that type of thing... and we have the mailing lists as a
record, etc.

Jenkins 1.453's borked partial release was enough to convince me that
dropping the staging repo and respining with the same version number is
probably the lesser evil though that might be because I had to go and
do some workarounds for some automated analysis and other fancy shit I was
doing.

I guess my point is that 3 months later I had to go digging and it took
quite some time to find out that Jenkins 1.453 was actually a failed
partial release and while there were artifacts for jenkins-core published,
there were none for jenkins-war.

Prior to 1.453 I would have been agreeing with KK's assertion that the ASF
version reuse was just madness.

But having said all that, if we can find a good way to flag versions as not
released (e.g. a release history page or something) I am not against
skipping version numbers. Might confuse people though if that meant that
the first release of Maven 3.1.0 was 3.1.4 (i.e. if we had not been doing
alpha's)

> -Jesse
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Apache 3.1.0-alpha-1

2013-05-29 Thread Olivier Lamy

2013/5/29 Stephen Connolly :
> On 29 May 2013 06:49, jieryn  wrote:
>
>> Greetings,
>>
>> On Wed, May 29, 2013 at 1:36 AM, Hervé BOUTEMY 
>> wrote:
>> > I'd like to work on Arnaud's idea of error message enhancement in case a
>> > plugin fails because of unavailable Sonatype Aether: if you can let me
>> 12 more
>> > hours from now, I'll do it tonight
>>
>> Version numbers are cheap. Can't we just make an alpha-2?
>>
>> I'm just a user, but I'm getting pretty sick of staged alpha releases
>> being dropped.
>>
>> This happened with 3.0.5 as well. Just release it already. They are
>> alphas. Christ.
>>
>
> Well for the NOTICE.txt issue, we cannot actually make a release for legal
> reasons without
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=b0a83f62
> being
> part of the release.
>
> The question is whether it is better to have the first 3.1.0 alpha release
> be called 3.1.0-alpha-4 or 3.1.0-alpha-1
>
> When people come back and look at the git history, they will see the
> commits with "[maven-release] Prepare 3.1.0-alpha-1" through to
> "[maven-release] Prepare 3.1.0-alpha-4" but only see the tag for
> maven-3.1.0-alpha-4 and they might incorrectly assume that somebody just
> forgot to push the tag (similarly they could undelete the SVN tag, so this
> is not a GIT thing) and then you could end up with a situation where the
> ASF is sued for making a release of Maven without attributing the Eclipse
> foundation correctly...
>
> Yes, I know that specific example is unlikely, but the point is that there
> is potential for that type of thing... and we have the mailing lists as a
> record, etc.
>
> Jenkins 1.453's borked partial release was enough to convince me that
> dropping the staging repo and respining with the same version number is
> probably the lesser evil though that might be because I had to go and
> do some workarounds for some automated analysis and other fancy shit I was
> doing.
>
> I guess my point is that 3 months later I had to go digging and it took
> quite some time to find out that Jenkins 1.453 was actually a failed
> partial release and while there were artifacts for jenkins-core published,
> there were none for jenkins-war.
>
> Prior to 1.453 I would have been agreeing with KK's assertion that the ASF
> version reuse was just madness.
>
> But having said all that, if we can find a good way to flag versions as not
> released (e.g. a release history page or something) I am not against
> skipping version numbers. Might confuse people though if that meant that
> the first release of Maven 3.1.0 was 3.1.4 (i.e. if we had not been doing
> alpha's)

it's just consuming a tag for "nothing" and not having an official
Apache release for this tag (not publishing sources or binaries)
Where is the issue ? some projects like httpd or tomcat do that.


>
>
>> -Jesse
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>



--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

Re: [VOTE] Apache 3.1.0-alpha-1

>
> But having said all that, if we can find a good way to flag versions as not
> released (e.g. a release history page or something) I am not against
> skipping version numbers. Might confuse people though if that meant that
> the first release of Maven 3.1.0 was 3.1.4 (i.e. if we had not been doing
> alpha's)
>
>
It is what Tomcat is doing ?
They release regularly and depending of feedback they announce it or not
AFAIR
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html
In the changelog (ex 7.0.38) you have a "not released" instead of the date
when they dropped it

Arnaud

Re: [VOTE] Apache 3.1.0-alpha-1

2013-05-29 Thread Kristian Rosenvold

Isn't the main source of confusion here that the "vote" thread is not
detached from the previous thread and that "Take X" is not added to
the subject ?

Kristian

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

Re: [VOTE] Apache 3.1.0-alpha-1

I am fine with it if there is a clear page which shows the status of each
release (i.e. linked from the downloads page:
http://maven.apache.org/download.cgi)

And if we want to go that way, I say let's just drop all the alpha crap.
and go for 3.1.0 straight.

My point is that there is a trade off... and as such there is no right or
wrong answer... only shades of grey

On 29 May 2013 09:17, Arnaud Héritier  wrote:

> >
> > But having said all that, if we can find a good way to flag versions as
> not
> > released (e.g. a release history page or something) I am not against
> > skipping version numbers. Might confuse people though if that meant that
> > the first release of Maven 3.1.0 was 3.1.4 (i.e. if we had not been doing
> > alpha's)
> >
> >
> It is what Tomcat is doing ?
> They release regularly and depending of feedback they announce it or not
> AFAIR
> http://tomcat.apache.org/tomcat-7.0-doc/changelog.html
> In the changelog (ex 7.0.38) you have a "not released" instead of the date
> when they dropped it
>
> Arnaud
>

RE: core-integration-testing-maven-3-jdk-1.7 - Build # 651 - Still Failing

Hi,


Sharing some information:
  -- Build on linux box (fedora, Jenkins 1516)
  What I understand of the job is 
Phase 1)
 clone maven source 
 Remove .repository
 ant build all on local repository.repository 
maven stored in apache-maven-3-SNAPSHOT

Phase 2)
   Clone maven integration source
   Remove  it-local-repo 
   use maven from phase 1) use two local repositories:
 it-local-repo
   .repository 
   
Is the configuration of two local repository something wanted?

Naïve try to limit (what I consider as)side effect:  I put one local
repository (it-local-repo) in phase 2:
Two integration test fail.
  MavenITmng3477DependencyResolutionErrorMessageTest
  MavenITmng3703ExecutionProjectWithRelativePathsTest

Regards,

Eric



-Message d'origine-
De : Hervé BOUTEMY [mailto:herve.bout...@free.fr] 
Envoyé : lundi 20 mai 2013 10:09
À : dev@maven.apache.org
Objet : Re: core-integration-testing-maven-3-jdk-1.7 - Build # 651 - Still
Failing

I don't undesrtand the last failure:
- it works on my machine
- ArtifactNotFoundException: Could not find artifact
org.apache.maven.skins:maven-default-skin:jar:1.0 in central
(file:target/null), but it is available in the local repository [1]

If someone knows what's happenning...

Regards,

Hervé

[1]
https://builds.apache.org/job/core-integration-testing-maven-3-jdk-1.7/ws/.r
epository/org/apache/maven/skins/maven-default-skin/1.0/

Le lundi 20 mai 2013 02:36:12 vous avez écrit :
> The Apache Jenkins build system has built
> core-integration-testing-maven-3-jdk-1.7 (build #651)
> 
> Status: Still Failing
> 
> Check console output at
> https://builds.apache.org/job/core-integration-testing-maven-3-jdk-1.7
> /651/
> to view the results.



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

Re: [VOTE] Apache 3.1.0-alpha-1

2013-05-29 Thread Olivier Lamy

Yup tomcat does it.

compare
http://archive.apache.org/dist/tomcat/tomcat-7/
with
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/

and
http://archive.apache.org/dist/tomcat/tomcat-6/
with
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/

2013/5/29 Kristian Rosenvold :
> Isn't the main source of confusion here that the "vote" thread is not
> detached from the previous thread and that "Take X" is not added to
> the subject ?
>
> Kristian
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

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

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?

+1 (binding)


On 29 May 2013 11:01, 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?

2013-05-29 Thread Tony Chemit

On Wed, 29 May 2013 11:01:25 +0100
Stephen Connolly  wrote:

+1 (at last ;))

tony (non binding)

> +1 (binding)
> 
> 
> On 29 May 2013 11:01, 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
> >



-- 
Tony Chemit

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

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

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

2013-05-29 Thread Kristian Rosenvold

-1

Den 29. mai 2013 kl. 12:04 skrev Tony Chemit :

> On Wed, 29 May 2013 11:01:25 +0100
> Stephen Connolly  wrote:
>
> +1 (at last ;))
>
> tony (non binding)
>
>> +1 (binding)
>>
>>
>> On 29 May 2013 11:01, 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
>
>
>
> --
> Tony Chemit
> 
> tél: +33 (0) 2 40 50 29 28
> email: che...@codelutin.com
> http://www.codelutin.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

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

2013-05-29 Thread Lukas Theussl


-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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

2013-05-29 Thread Jörg Schaible

-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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

RE: CALL TO CONTRIBUTION: dist tooling

It finally works(svn client issue reinstalling older tortoiseSVN)
http://svn.apache.org/r1487396 

sorry for stress...

-Message d'origine-
De : Olivier Lamy [mailto:ol...@apache.org] 
Envoyé : mercredi 29 mai 2013 10:09
À : Maven Developers List
Objet : Re: CALL TO CONTRIBUTION: dist tooling

weird.
what is the error message ? and svn url you are using ?

2013/5/29 Eric Barboni :
> Sorry, but Maven sandbox is write protected for me.
>
> I created a svn patch file but I don't know where to fill the issue 
> (project, component in jira).
>
> Regards,
>
> Eric
>
> -Message d'origine-
> De : Hervé BOUTEMY [mailto:herve.bout...@free.fr] Envoyé : mardi 28 
> mai 2013 22:44 À : Maven Developers List Objet : Re: CALL TO 
> CONTRIBUTION: dist tooling
>
> great!
> thanks for your help
>
> yes, a maven plugin can be a solution, even if report is overkill 
> IMHO: we won't publish result
>
> Maven sandbox [1] should be writeable to any Apache committer, IIUC
>
> Regards,
>
> Hervé
>
> [1] https://svn.apache.org/repos/asf/maven/sandbox/trunk/
>
> Le mardi 28 mai 2013 17:54:31 Eric Barboni a écrit :
>> Hi,
>>
>>   If still open, I'm interested to help on this part.
>>
>>  Can it be a maven plugin with html report (A bit overkill maybe but
> scripts
>> on windows are annoying)   ?
>>
>> Where should the tool be located in the scm tree (to facilitate patch
>> creation) ?
>>
>>  Regards,
>>
>> Eric
>>
>> -Message d'origine-
>> De : Hervé BOUTEMY [mailto:herve.bout...@free.fr] Envoyé : mercredi 
>> 24 avril 2013 13:23 À : Maven Developers List Objet : CALL TO
>> CONTRIBUTION: dist tooling
>>
>> I just did some checks in our distribution area [1] and found a good 
>> number of missing releases In addition to asking committers to 
>> remember our procedure [2] (and ask for PMC help if necessary) , I 
>> just thought it would be good to have a little tool to check against
> latest artifact releases:
>> with a little config file giving groupId:artifactId and directory in 
>> dist, it could check if latest version from central metadata [3] is 
>> actually published in dist and warn if not.
>>
>> This is a first step, since a lot more help can be added later, I 
>> have a good number of ideas (download the new release, propose svn 
>> commands to remove old releases and add new ones, check consistency 
>> with site,
>> ...)
>>
>> But I don't want to code it right now and prefer concentrate working 
>> on
>> maven- site-plugin, dependency:tree and so on related le future Maven 
>> version.
>>
>> I thought this could be a good opportunity for someone to do somthing 
>> without having to learn too much on existing code.
>>
>> Is there anybody interested?
>>
>> Regards,
>>
>> Hervé
>>
>>
>> [1] https://dist.apache.org/repos/dist/release/maven/
>>
>> [2] 
>> http://maven.apache.org/developers/release/maven-project-release->
>> procedure.html#Copy_the_source_release_to_the_Apache_Distribution_Are
>> a
>>
>> [3]
>> http://repo.maven.apache.org/maven2/org/apache/maven/reporting/maven-
>> >
>> reporting-exec/maven-metadata.xml
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For 
>> additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For 
> additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For 
> additional commands, e-mail: dev-h...@maven.apache.org
>



--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

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



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

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

+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  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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

2013-05-29 Thread Gary Gregory

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.conno...@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: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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

Moving discussion off the vote thread

The issue with that is when using the Maven Release Plugin, you will not be
voting on the released artifacts if you call it x.y.z-RCn, so you would
need a whole new vote for x.y.z.

We could go all Eclipse nutjob and force the timestamp into every release,
e.g.

3.1.0.v20130529

But that way madness lies in my view... In any case, we will see where the
vote goes... and if there is a non-definitive answer, e.g. (-3 < ∑ binding
votes < 3) then we can see what alternatives fall out of the mix.


On 29 May 2013 12:10, Gary Gregory  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.conno...@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: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

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

2013-05-29 Thread Gary Gregory

On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Moving discussion off the vote thread
>
> The issue with that is when using the Maven Release Plugin, you will not be
> voting on the released artifacts if you call it x.y.z-RCn, so you would
> need a whole new vote for x.y.z.
>

The /[vote]/ and the /SVN tag/ are called x.y.z-RCn, the artifacts in the
Nexus staging repo are marked x.y.z.

Gary

>
> We could go all Eclipse nutjob and force the timestamp into every release,
> e.g.
>
> 3.1.0.v20130529
>
> But that way madness lies in my view... In any case, we will see where the
> vote goes... and if there is a non-definitive answer, e.g. (-3 < ∑ binding
> votes < 3) then we can see what alternatives fall out of the mix.
>
>
> On 29 May 2013 12:10, Gary Gregory  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.conno...@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: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition<
> > http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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

Ahh, so that is just a nicer way of handling the respin with same version
number. In any case we currently have a ∑ binding = 0 so no decision
forthcoming yet... but early days ;-)


On 29 May 2013 12:31, Gary Gregory  wrote:

> On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Moving discussion off the vote thread
> >
> > The issue with that is when using the Maven Release Plugin, you will not
> be
> > voting on the released artifacts if you call it x.y.z-RCn, so you would
> > need a whole new vote for x.y.z.
> >
>
> The /[vote]/ and the /SVN tag/ are called x.y.z-RCn, the artifacts in the
> Nexus staging repo are marked x.y.z.
>
> Gary
>
> >
> > We could go all Eclipse nutjob and force the timestamp into every
> release,
> > e.g.
> >
> > 3.1.0.v20130529
> >
> > But that way madness lies in my view... In any case, we will see where
> the
> > vote goes... and if there is a non-definitive answer, e.g. (-3 < ∑
> binding
> > votes < 3) then we can see what alternatives fall out of the mix.
> >
> >
> > On 29 May 2013 12:10, Gary Gregory  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.conno...@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: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition<
> > > http://www.manning.com/bauer3/>
> > > JUnit in Action, Second Edition 
> > > Spring Batch in Action 
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

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

2013-05-29 Thread Jeff Jensen

It seems that most people care about X.Y and X.Y.Z numbers of the
versioning scheme, not X.Y.Z.N.  To spin through version numbers without
concern during release candidates, perhaps using the 4th position, N, would
then allow continued use of the familiar X.Y and X.Y.Z references?
 Major.Minor.Point/bug.RC.  It's arbitrary precision, but maintains the
X.Y.Z format, and Z doesn't have "skipped numbers".




On Wed, May 29, 2013 at 6:31 AM, Gary Gregory wrote:

> On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Moving discussion off the vote thread
> >
> > The issue with that is when using the Maven Release Plugin, you will not
> be
> > voting on the released artifacts if you call it x.y.z-RCn, so you would
> > need a whole new vote for x.y.z.
> >
>
> The /[vote]/ and the /SVN tag/ are called x.y.z-RCn, the artifacts in the
> Nexus staging repo are marked x.y.z.
>
> Gary
>
> >
> > We could go all Eclipse nutjob and force the timestamp into every
> release,
> > e.g.
> >
> > 3.1.0.v20130529
> >
> > But that way madness lies in my view... In any case, we will see where
> the
> > vote goes... and if there is a non-definitive answer, e.g. (-3 < ∑
> binding
> > votes < 3) then we can see what alternatives fall out of the mix.
> >
> >
> > On 29 May 2013 12:10, Gary Gregory  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.conno...@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: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition<
> > > http://www.manning.com/bauer3/>
> > > JUnit in Action, Second Edition 
> > > Spring Batch in Action 
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action

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

I'm totally fine with the 1.0-RC0 1.0-RC1 1.0-RC2 == 1.0 thing, in Git you
don't even have to copy anything ;-)

If you're going to do trial releases, then RCX is one good way to do it.

I've got to point out, though, that "skipped numbers" means exactly NOTHING
:-) You *always* skip numbers, by definition, every time you jump to a new
version of a greater number in the next higher slot... eg:

1.1 1.2 1.3 1.4 1.5 1.6 2.0 < you missed 1.7 and 1.8, OMG :-p

Fred.

On Wed, May 29, 2013 at 1:54 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Ahh, so that is just a nicer way of handling the respin with same version
> number. In any case we currently have a ∑ binding = 0 so no decision
> forthcoming yet... but early days ;-)
>
>
> On 29 May 2013 12:31, Gary Gregory  wrote:
>
> > On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > Moving discussion off the vote thread
> > >
> > > The issue with that is when using the Maven Release Plugin, you will
> not
> > be
> > > voting on the released artifacts if you call it x.y.z-RCn, so you would
> > > need a whole new vote for x.y.z.
> > >
> >
> > The /[vote]/ and the /SVN tag/ are called x.y.z-RCn, the artifacts in the
> > Nexus staging repo are marked x.y.z.
> >
> > Gary
> >
> > >
> > > We could go all Eclipse nutjob and force the timestamp into every
> > release,
> > > e.g.
> > >
> > > 3.1.0.v20130529
> > >
> > > But that way madness lies in my view... In any case, we will see where
> > the
> > > vote goes... and if there is a non-definitive answer, e.g. (-3 < ∑
> > binding
> > > votes < 3) then we can see what alternatives fall out of the mix.
> > >
> > >
> > > On 29 May 2013 12:10, Gary Gregory  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.conno...@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: garydgreg...@gmail.com | ggreg...@apache.org
> > > > Java Persistence w

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

+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 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.conno...@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: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> 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: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?

2013-05-29 Thread Barrie Treloar

On 29 May 2013 20:53, Stephen Connolly  wrote:
> The issue with that is when using the Maven Release Plugin, you will not be
...

Can't we fix the tooling then?

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

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

Actually clarified that the release plugin is being used but the tag is
being forced to a different name and then moved post successful release,
e.g.

mvn release:prepate release:perform -DreleaseVersion=3.1.0 -Dtag=3.1.0-RC1

Now there is an issue with that in that the pom will contain the wrong tag
in the scm section...

$ svn log --limit 5 -v
https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.5

r1456364 | bodewig | 2013-03-14 08:43:27 + (Thu, 14 Mar 2013) | 1 line
Changed paths:
   A /commons/proper/compress/tags/COMPRESS-1.5 (from
/commons/proper/compress/tags/COMPRESS-1.5_RC1:1456363)

Vote has passed, 1.5 is released

r1455005 | bodewig | 2013-03-11 06:10:51 + (Mon, 11 Mar 2013) | 1 line
Changed paths:
   A /commons/proper/compress/tags/COMPRESS-1.5_RC1 (from
/commons/proper/compress/trunk:1455004)
   M /commons/proper/compress/tags/COMPRESS-1.5_RC1/pom.xml

Tagging first RC for Compress 1.5


So they are not using the release plugin then... perhaps a pseudo-tag
option is needed for the release plugin then...

On 29 May 2013 13:40, Barrie Treloar  wrote:

> On 29 May 2013 20:53, Stephen Connolly 
> wrote:
> > The issue with that is when using the Maven Release Plugin, you will not
> be
> ...
>
> Can't we fix the tooling then?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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

2013-05-29 Thread Daniel Kulp

+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  
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
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


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

Re: [VOTE] Apache 3.1.0-alpha-1

2013-05-29 Thread Jason van Zyl

Sure, go for it. The less confusing to users the better.

On May 29, 2013, at 1:36 AM, Hervé BOUTEMY  wrote:

> I'd like to work on Arnaud's idea of error message enhancement in case a 
> plugin fails because of unavailable Sonatype Aether: if you can let me 12 
> more 
> hours from now, I'll do it tonight
> 
> Regards,
> 
> Hervé
> 
> Le mardi 28 mai 2013 19:21:52 Jason van Zyl a écrit :
>> I'll see if Robert wants to fix the DOAP file and I'll respin tomorrow after
>> he's commented.
>> On May 28, 2013, at 7:17 PM, Stephen Connolly 
>  wrote:
>>> Yep looks fine to me. If you want to respin now, from _my_ PoV
>>> *should*
>>> be no issues now... of course who knows what will crop up with the next
>>> review ;-)
>>> 
>>> On 29 May 2013 00:07, Jason van Zyl  wrote:
 This should suffice for the notice:
 
 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=b0a83f
 62
 
 On May 28, 2013, at 5:48 PM, Stephen Connolly <
 
 stephen.alan.conno...@gmail.com> wrote:
> From my PoV the only outstanding issue is that the NOTICE.txt does not
> reflect the fact that it is now Eclipse Aether and no longer Sonatype
> Aether.
> 
> I am unclear what the exact wording that is required, I am hoping that
> somebody else can correct the file. All the license header issues are,
> to
> my mind, fixed on master and Robert has switched over to
 
 package-info.java.
 
> I'll let Robert comment as to whether he sees the DOAP as a blocker.
> 
> On 28 May 2013 22:08, Jason van Zyl  wrote:
>> It's very easy to cut another release. If all the fixes are in that the
>> PMC wishes it takes minutes to roll the release again.
>> 
>> On May 28, 2013, at 4:43 PM, Robert Scholte 
 
 wrote:
>>> Some additional remarks:
>>> - The copyright doesn't include current year (I've already fixed that
 
 on
 
>> the trunk)
>> 
>>> - doap:generate fails: The generated DOAP doesn't respect ASF rules.
>>> 
>>> Just to be sure I understand correctly: these alpha-versions will
>>> never
>> 
>> be released. They are created so users can try them. -1 votes would
 
 mean it
 
>> is not yet ready for a beta or final release. Is this right?
>> 
>>> Robert
>>> 
>>> Op Tue, 28 May 2013 10:38:07 +0200 schreef Stephen Connolly <
>> 
>> stephen.alan.conno...@gmail.com>:
 [x] Builds from source bundle
 [x] Builds some complex projects
 [x] Contains correct LICENSE.txt
 [ ] NOTICE.txt correctly attributes 3rd party components (See
>> 
>> observation 1)
>> 
 [?] All source files, where appropriate, contain the ASL header (See
 observation 2)
 [?] Binary archives bundled within the source distribution (See
>> 
>> observation
>> 
 3)
 
 On the basis of the NOTICE.txt not acknowledging Eclipse Aether, and
>> 
>> only
>> 
 on that basis I will be voting
 
 -0.9 (binding)
 
 The other issues are non-critical but it would be nice to tidy them
>> 
>> up...
>> 
 nice to have.
 
 Observations
 
 1. No attribution of Eclipse Aether, only referenced as developed by
 Sonatype.
 
 2. The following 39 files are missing license headers:
 
 apache-maven/src/bin/m2.conf
 apache-maven/src/conf/logging/simplelogger.properties
 
 maven-aether-provider/src/main/java/org/apache/maven/repository/internal/
 package.html>> 
 maven-aether-provider/src/site/apt/index.apt
 maven-artifact/src/site/apt/index.apt
 maven-compat/compatibility.cfl
 maven-compat/src/main/resources/META-INF/maven/plugin.xml
 maven-core/lifecycle-executor.txt
 maven-core/plugin-manager.txt
 maven-core/project-builder.txt
>> 
>> maven-core/src/main/resources/org/apache/maven/messages/build.propertie
>> s
>> 
 maven-core/src/site/apt/artifact-handlers.apt
 maven-core/src/site/apt/configuration-management.apt
 maven-core/src/site/apt/default-bindings.apt.vm
 maven-core/src/site/apt/getting-to-container-configured-mojos.apt
 maven-core/src/site/apt/index.apt
 maven-core/src/site/apt/inheritance.apt
 maven-core/src/site/apt/lifecycles.apt.vm
 maven-core/src/site/apt/offline-mode.apt
 maven-core/src/site/apt/plugin-execution-isolation.apt
 maven-core/src/site/apt/scripting-support/marmalade-support.apt
 maven-core/src/site/resources/design/2.1-lifecycle-refactor.graffle
 
 maven-embedder/src/examples/simple-project/src/main/java/org/apache/maven
 /embedder/App.java
 
 
 
 maven-embedder/src/examples/simple-project/src/test/java/org/apache/maven
 /embedder/App

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

You're voting on a set of sources, and the state of them, more than the
specific binary built on a specific platform. You're not really voting on
the arbitrary binary that manifests itself as a result of those sources and
build. Although it's possible to build from the same sources and get a
(meaningfully) different binary, the chances of that are slim to none
provided the developer is using the same box/dir/tools and the project is
configured correctly. This can be handled by convention and discipline.

RC releases should be done as full blown releases with no extra flags,
tagged and versioned throughout as what they are. Once an RC is accepted,
simply adjust the version and release from the commit after the one the
last RC came from (with a diff that is purely pom version field change).
This is in Git terms. You're talking in SVN terms. These are impl details
of the same approach.

There are many ways to skin this cat acceptably. The main criteria (in my
mind) is that no two binaries are built with the same version number.

Rebuilding from the new tag (or just new commit in Git) can be handled by
staging that one binary, and simply skipping it if the dev screwed
something up.

You could also just skip the RC stuff, which is pretty normal in typical
maven-built stuff anyway, and never publish bad bins to central resulting
in 1.1 1.7 1.24 2.0 in central.

Even the matching binaries could be OK if there is a procedure to manually
publish the hashes of the artifacts in question in the email announcement
such that the intent of the developer can be checked against the reality
down stream. Something like "I've released 0.1 of XYZ, with jar of hash
abcdef123 and pom of hash 123456fedcba". with those hashes differing on the
second try (if required).

As stated, though, typically not many, if any, tries are required, as
plenty of snapshots have been tried, and lots of testing is done on the
sources intended to be released.

Fred.

On Wed, May 29, 2013 at 2:53 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Actually clarified that the release plugin is being used but the tag is
> being forced to a different name and then moved post successful release,
> e.g.
>
> mvn release:prepate release:perform -DreleaseVersion=3.1.0 -Dtag=3.1.0-RC1
>
> Now there is an issue with that in that the pom will contain the wrong tag
> in the scm section...
>
> $ svn log --limit 5 -v
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.5
> 
> r1456364 | bodewig | 2013-03-14 08:43:27 + (Thu, 14 Mar 2013) | 1 line
> Changed paths:
>A /commons/proper/compress/tags/COMPRESS-1.5 (from
> /commons/proper/compress/tags/COMPRESS-1.5_RC1:1456363)
>
> Vote has passed, 1.5 is released
> 
> r1455005 | bodewig | 2013-03-11 06:10:51 + (Mon, 11 Mar 2013) | 1 line
> Changed paths:
>A /commons/proper/compress/tags/COMPRESS-1.5_RC1 (from
> /commons/proper/compress/trunk:1455004)
>M /commons/proper/compress/tags/COMPRESS-1.5_RC1/pom.xml
>
> Tagging first RC for Compress 1.5
> 
>
> So they are not using the release plugin then... perhaps a pseudo-tag
> option is needed for the release plugin then...
>
> On 29 May 2013 13:40, Barrie Treloar  wrote:
>
> > On 29 May 2013 20:53, Stephen Connolly 
> > wrote:
> > > The issue with that is when using the Maven Release Plugin, you will
> not
> > be
> > ...
> >
> > Can't we fix the tooling then?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

RE: CALL TO CONTRIBUTION: dist tooling


It finally works(svn client issue reinstalling older tortoiseSVN)
http://svn.apache.org/r1487396 

sorry for stress...

-Message d'origine-
De : Olivier Lamy [mailto:ol...@apache.org] 
Envoyé : mercredi 29 mai 2013 10:09
À : Maven Developers List
Objet : Re: CALL TO CONTRIBUTION: dist tooling

weird.
what is the error message ? and svn url you are using ?

2013/5/29 Eric Barboni :
> Sorry, but Maven sandbox is write protected for me.
>
> I created a svn patch file but I don't know where to fill the issue 
> (project, component in jira).
>
> Regards,
>
> Eric
>
> -Message d'origine-
> De : Hervé BOUTEMY [mailto:herve.bout...@free.fr] Envoyé : mardi 28 
> mai 2013 22:44 À : Maven Developers List Objet : Re: CALL TO 
> CONTRIBUTION: dist tooling
>
> great!
> thanks for your help
>
> yes, a maven plugin can be a solution, even if report is overkill 
> IMHO: we won't publish result
>
> Maven sandbox [1] should be writeable to any Apache committer, IIUC
>
> Regards,
>
> Hervé
>
> [1] https://svn.apache.org/repos/asf/maven/sandbox/trunk/
>
> Le mardi 28 mai 2013 17:54:31 Eric Barboni a écrit :
>> Hi,
>>
>>   If still open, I'm interested to help on this part.
>>
>>  Can it be a maven plugin with html report (A bit overkill maybe but
> scripts
>> on windows are annoying)   ?
>>
>> Where should the tool be located in the scm tree (to facilitate patch
>> creation) ?
>>
>>  Regards,
>>
>> Eric
>>
>> -Message d'origine-
>> De : Hervé BOUTEMY [mailto:herve.bout...@free.fr] Envoyé : mercredi 
>> 24 avril 2013 13:23 À : Maven Developers List Objet : CALL TO
>> CONTRIBUTION: dist tooling
>>
>> I just did some checks in our distribution area [1] and found a good 
>> number of missing releases In addition to asking committers to 
>> remember our procedure [2] (and ask for PMC help if necessary) , I 
>> just thought it would be good to have a little tool to check against
> latest artifact releases:
>> with a little config file giving groupId:artifactId and directory in 
>> dist, it could check if latest version from central metadata [3] is 
>> actually published in dist and warn if not.
>>
>> This is a first step, since a lot more help can be added later, I 
>> have a good number of ideas (download the new release, propose svn 
>> commands to remove old releases and add new ones, check consistency 
>> with site,
>> ...)
>>
>> But I don't want to code it right now and prefer concentrate working 
>> on
>> maven- site-plugin, dependency:tree and so on related le future Maven 
>> version.
>>
>> I thought this could be a good opportunity for someone to do somthing 
>> without having to learn too much on existing code.
>>
>> Is there anybody interested?
>>
>> Regards,
>>
>> Hervé
>>
>>
>> [1] https://dist.apache.org/repos/dist/release/maven/
>>
>> [2] 
>> http://maven.apache.org/developers/release/maven-project-release->
>> procedure.html#Copy_the_source_release_to_the_Apache_Distribution_Are
>> a
>>
>> [3]
>> http://repo.maven.apache.org/maven2/org/apache/maven/reporting/maven-
>> >
>> reporting-exec/maven-metadata.xml
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For 
>> additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For 
> additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For 
> additional commands, e-mail: dev-h...@maven.apache.org
>



--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

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



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

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

2013-05-29 Thread Robert Scholte


-1 (binding) on actual releases

Robert


Op Wed, 29 May 2013 15:20:17 +0200 schreef Daniel Kulp :

+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  
 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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Apache 3.1.0-alpha-1

2013-05-29 Thread Robert Scholte

DOAP issues have been fixed. Let's wait for Hervé before spinning a new  
release.


Robert


Op Wed, 29 May 2013 01:21:52 +0200 schreef Jason van Zyl :

I'll see if Robert wants to fix the DOAP file and I'll respin tomorrow  
after he's commented.


On May 28, 2013, at 7:17 PM, Stephen Connolly  
 wrote:


Yep looks fine to me. If you want to respin now, from _my_ PoV  
*should*

be no issues now... of course who knows what will crop up with the next
review ;-)


On 29 May 2013 00:07, Jason van Zyl  wrote:


This should suffice for the notice:

https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=b0a83f62

On May 28, 2013, at 5:48 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


From my PoV the only outstanding issue is that the NOTICE.txt does not
reflect the fact that it is now Eclipse Aether and no longer Sonatype
Aether.

I am unclear what the exact wording that is required, I am hoping that
somebody else can correct the file. All the license header issues  
are, to

my mind, fixed on master and Robert has switched over to

package-info.java.


I'll let Robert comment as to whether he sees the DOAP as a blocker.


On 28 May 2013 22:08, Jason van Zyl  wrote:

It's very easy to cut another release. If all the fixes are in that  
the

PMC wishes it takes minutes to roll the release again.

On May 28, 2013, at 4:43 PM, Robert Scholte 

wrote:



Some additional remarks:
- The copyright doesn't include current year (I've already fixed  
that

on

the trunk)

- doap:generate fails: The generated DOAP doesn't respect ASF rules.

Just to be sure I understand correctly: these alpha-versions will  
never

be released. They are created so users can try them. -1 votes would

mean it

is not yet ready for a beta or final release. Is this right?


Robert

Op Tue, 28 May 2013 10:38:07 +0200 schreef Stephen Connolly <

stephen.alan.conno...@gmail.com>:



[x] Builds from source bundle
[x] Builds some complex projects
[x] Contains correct LICENSE.txt
[ ] NOTICE.txt correctly attributes 3rd party components (See

observation 1)
[?] All source files, where appropriate, contain the ASL header  
(See

observation 2)
[?] Binary archives bundled within the source distribution (See

observation

3)

On the basis of the NOTICE.txt not acknowledging Eclipse Aether,  
and

only

on that basis I will be voting

-0.9 (binding)

The other issues are non-critical but it would be nice to tidy them

up...

nice to have.

Observations

1. No attribution of Eclipse Aether, only referenced as developed  
by

Sonatype.

2. The following 39 files are missing license headers:

apache-maven/src/bin/m2.conf
apache-maven/src/conf/logging/simplelogger.properties





maven-aether-provider/src/main/java/org/apache/maven/repository/internal/package.html

maven-aether-provider/src/site/apt/index.apt
maven-artifact/src/site/apt/index.apt
maven-compat/compatibility.cfl
maven-compat/src/main/resources/META-INF/maven/plugin.xml
maven-core/lifecycle-executor.txt
maven-core/plugin-manager.txt
maven-core/project-builder.txt


maven-core/src/main/resources/org/apache/maven/messages/build.properties

maven-core/src/site/apt/artifact-handlers.apt
maven-core/src/site/apt/configuration-management.apt
maven-core/src/site/apt/default-bindings.apt.vm
maven-core/src/site/apt/getting-to-container-configured-mojos.apt
maven-core/src/site/apt/index.apt
maven-core/src/site/apt/inheritance.apt
maven-core/src/site/apt/lifecycles.apt.vm
maven-core/src/site/apt/offline-mode.apt
maven-core/src/site/apt/plugin-execution-isolation.apt
maven-core/src/site/apt/scripting-support/marmalade-support.apt
maven-core/src/site/resources/design/2.1-lifecycle-refactor.graffle





maven-embedder/src/examples/simple-project/src/main/java/org/apache/maven/embedder/App.java






maven-embedder/src/examples/simple-project/src/test/java/org/apache/maven/embedder/AppTest.java

maven-embedder/src/main/resources/META-INF/MANIFEST.MF





maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties

maven-embedder/src/site/apt/cli.apt.vm
maven-embedder/src/site/apt/index.apt.vm
maven-embedder/src/site/apt/logging.apt
maven-model-builder/src/site/apt/index.apt
maven-model-builder/src/site/apt/super-pom.apt.vm
maven-model/src/main/java/org/apache/maven/model/io/xpp3/package.html
maven-model/src/main/java/org/apache/maven/model/merge/package.html
maven-model/src/main/java/org/apache/maven/model/package.html
maven-model/src/site/apt/index.apt
maven-plugin-api/src/site/apt/index.apt
maven-repository-metadata/src/site/apt/index.apt
maven-settings/src/site/apt/index.apt
README.bootstrap.txt

None of these are actual production code, so I don't see this as a

blocker
for release, but it would be good to tidy them up. Additionally,  
the

embedder examples should have their license explicitly stated to

remove

confusion for anyone pegging the examples to build their own code

upon.


In addition I note that there are 432 test resources that do

maven-surefire pull request: SUREFIRE-999: Skip phase `validate` during sit...

2013-05-29 Thread mfriedenhagen

GitHub user mfriedenhagen opened a pull request:

https://github.com/apache/maven-surefire/pull/23

SUREFIRE-999: Skip phase `validate` during site-generation for 
`report-only` resp. `failsafe-report-only`

* We have a lot of projects in our CI system (Jenkins) where we run `mvn 
clean deploy site-deploy`.
* Because of this, we do not repeat test execution again during phase 
`site` by defining the `reportSet` to include `report-only`.
* However, `report-only` does invoke the phase validate again which will 
execute some lengthy enforcer checks.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mfriedenhagen/maven-surefire master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/23.patch


commit 4b23fef945acac31659232a4c6b367000e9a7079
Author: Mirko Friedenhagen 
Date:   2013-05-23T11:35:33Z

Do not enforce a new lifecycle in ReportOnly Mojos to speed up site build.

commit d7e022181631af43369611c86f7430159933df15
Author: Mirko Friedenhagen 
Date:   2013-05-27T20:20:15Z

Let SurefireReportOnlyMojo be a child of AbstractSurefireReportMojo to 
avoid execution of phase validate.




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

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

2013-05-29 Thread Wayne Fay

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

Wayne

On Wed, May 29, 2013 at 8:20 AM, Daniel Kulp  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 
>  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
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

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

2013-05-29 Thread Baptiste MATHUS

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 

> +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.schai...@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-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>



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

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

"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  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 
>
> > +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.schai...@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-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

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

2013-05-29 Thread Baptiste MATHUS

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 

> "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 
> 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 
> >
> > > +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.schai...@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-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> >
>



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

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