I agree with Dan and Wayne
+1 for "qualified" releases (alpha, beta, RC, etc…) that are working toward the
full blow release but aren't intended to be that.
-1 for the actual releases.
And I don't care if the next 3.1.0-alpha is alpha-2 or alpha-4: what I care is
that it is not alpha-1 any mor
MNG-5482 fixed: ok for me to go for take 4
when a plugin cannot be loaded due to missing Sonatype Aether class, hint url
will be http://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound
the Wiki article still needs to be written...
Regards,
Hervé
Le mercredi 29 mai 2013 09:34:46
What do we currently do for plugins?
What do we currently do for core?
Is there in difference in the approach taken?
We call for a vot for vX.Y.Z of (plugins's [recently at
least] do not appear to go throught he beta/RC phases).
Can someone please spell out a sequence of events (by time) as to w
Non-bindingly:
+1 for pre-releases
-1 for actual releases
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/
On Wed, May 29, 2013 at 10:00 PM, Baptiste MATHUS wrote:
> You're right, my bad. I just re-read the details
On Wed, May 29, 2013 at 10:17 AM, 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 firs
>
> -1 for actual releases: it would create more mess imo for end users if
> there's many bizarre jumps in numbering
The thing with this argument is that it's very, very weak. If a missed
version confuses a user, they're basically brain-dead. Assuming your users
are brain dead is _always_ dangero
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 Fre
"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 act
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
wi
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 2
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
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
-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,
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 tool
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
(meani
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
+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
> ve
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 t
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 additi
+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 [vo
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 de
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.Poin
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.con
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 who
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
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
+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
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 tooli
-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
-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 releas
-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 with
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
+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
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
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 sour
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)
Clo
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..
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 addit
>
> 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 doi
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
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
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
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
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
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 provid
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
grou
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 Developer
alpha-1 to n works fine imo. We should not loose pace by holding up the effort
with such minor stuff.
LieGrue,
strub
- Original Message -
> From: Baptiste Mathus
> To: Maven Developers List
> Cc:
> Sent: Wednesday, 29 May 2013, 8:47
> Subject: Re: [VOTE] Apache 3.1.0-alpha-1
>
> L
48 matches
Mail list logo
