You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benjamin Bentmann <be...@udo.edu> on 2009/11/23 17:33:24 UTC
[VOTE] Release Apache Maven 3.0-alpha-5
Hi,
We solved some more issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14952
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
Staging repo:
https://repository.apache.org/content/repositories/maven-018/
Staged source and binary distros:
https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html
Vote open for 72 hours.
[ ] +1
[ ] +0
[ ] -1
+1 from me
Benjamim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Olivier Lamy <ol...@apache.org>.
+1
2009/11/23 Benjamin Bentmann <be...@udo.edu>:
> Hi,
>
> We solved some more issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14952
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-018/
>
> Staged source and binary distros:
> https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> +1 from me
>
>
> Benjamim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Stephen Connolly <st...@gmail.com>.
2009/11/26 Paul Benedict <pb...@apache.org>:
> I would also like to contribute my frustration with the current build
> process. It's great the alpha releases are coming out often, but I
> cannot possibly be testing them at the frequency you guys are
> currently tagging and voting. I thought the "once a week" alpha was a
> good idea until it actually happened. If you guys voted once every
> three weeks, it would be much easier for me to participate. I wonder
> if others believe the same.
IMHO, once a week vs once every three weeks makes little difference.
The important metric is is the next release X bugs better than the
last release.
Personally, if at least 5 bugs have been fixed and it has been at
least 1 week since the last alpha, I say run a release again
especially given that running a release of a 3.0-alpha seems to be so
much easier. These are alpha's, we have a great IT framework (thanks
to benjamin), so voting +1 has got to be easier. If you don't feel
like testing every release, test every other release and only vote
only for those you feel comfortable voting for (i.e. you tested)
-Stephen
>
> Paul
>
> On Wed, Nov 25, 2009 at 7:48 PM, Jason van Zyl <ja...@maven.org> wrote:
>> Let's not beat the dead horse. No one cares. There's not good reason for not
>> releasing something immediately if there are fixes available. That's just
>> not the way it works here, that's fine and not a big deal.
>>
>> On 2009-11-25, at 7:52 PM, Brett Porter wrote:
>>
>>>
>>> On 26/11/2009, at 6:24 AM, Jason van Zyl wrote:
>>>
>>>> If ever we really needed to push out builds more frequently I would just
>>>> do it from Sonatype. I've given up trying to be truly agile at Apache, it's
>>>> just not going to happen.
>>>
>>> I don't understand what the issue is with the current process. Benjamin is
>>> already getting them out faster than the majority of people will be able to
>>> test and review them. Any faster and you might as well just be using the CI
>>> builds for whatever purpose you have in mind. You're not going to be able to
>>> push out anything from Sonatype that's any more official than those, so what
>>> benefit does anyone get from a build that loses the frequency of CI builds
>>> and loses the benefit of being reviewed before publishing?
>>>
>>> The rules about not promoting snapshots to users are there for good
>>> reasons - to make sure the PMC does actually authorize releases and the
>>> users know what they are getting, and to encourage actually doing releases
>>> (instead of everyone running their own version of trunk). I don't see any
>>> upside to a change that loses those. There's no problem pointing individuals
>>> to the grid for *testing* purposes as far as I know, as long as they know
>>> what they are getting is not a release and may not work at all.
>>>
>>> Thanks,
>>> Brett
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Jason van Zyl <ja...@maven.org>.
On 2009-11-26, at 11:04 AM, Ralph Goers wrote:
>
> On Nov 26, 2009, at 5:04 AM, Todd Thiessen wrote:
>
>> I can only speak from experience with what we have done here
>> internally but I can also attest that releasing too often is a real
>> pain. You end up having a bunch of releases publicized that no one
>> cares about. It only serves to clutter a repository and makes it
>> confusing to consumers wrt which one to use.
>
> Users just use the latest one you give them.
That's not been the case with the 3.x alphas. We have lots of people
picking them up especially the alpha-5.
> Most users will avoid a release named project-n.n-alpha-n because
> they don't want to screw around with stuff that is unstable.
> However, there will be a tiny set of users for which the particular
> fixes in the alpha is important.
>
>>
>> I love the agile model of development but I don't think this
>> equates to "releasing something immediately if there are fixes
>> available" as Jason put it. The release needs to be weighed against
>> the value it provides and the extra time and effort the community
>> needs to soak and test that release. Agile states that your
>> software should be releasable at anytime, but it does not state
>> that it should be continually released.
>
> Releases named "alpha or beta" are for testing new functionality.
> They should not be considered release candidates and they certainly
> should not be used for production purposes. I would be much more
> concerned if these were non-alpha or beta type releases.
>
> Yes, I have found it difficult to keep up with the pace and have so
> far been only able to test one alpha. Since 3 votes are required to
> approve a release I would assume that various PMC members are
> confirming different releases. However, if it gets to the point
> where releases are being approved only by members with the same
> affiliation then I would be concerned.
>
> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Ralph Goers <ra...@dslextreme.com>.
On Nov 26, 2009, at 5:04 AM, Todd Thiessen wrote:
> I can only speak from experience with what we have done here internally but I can also attest that releasing too often is a real pain. You end up having a bunch of releases publicized that no one cares about. It only serves to clutter a repository and makes it confusing to consumers wrt which one to use.
Users just use the latest one you give them. Most users will avoid a release named project-n.n-alpha-n because they don't want to screw around with stuff that is unstable. However, there will be a tiny set of users for which the particular fixes in the alpha is important.
>
> I love the agile model of development but I don't think this equates to "releasing something immediately if there are fixes available" as Jason put it. The release needs to be weighed against the value it provides and the extra time and effort the community needs to soak and test that release. Agile states that your software should be releasable at anytime, but it does not state that it should be continually released.
Releases named "alpha or beta" are for testing new functionality. They should not be considered release candidates and they certainly should not be used for production purposes. I would be much more concerned if these were non-alpha or beta type releases.
Yes, I have found it difficult to keep up with the pace and have so far been only able to test one alpha. Since 3 votes are required to approve a release I would assume that various PMC members are confirming different releases. However, if it gets to the point where releases are being approved only by members with the same affiliation then I would be concerned.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Brian Fox <br...@infinity.nu>.
On Fri, Nov 27, 2009 at 3:42 PM, Brett Porter <br...@apache.org> wrote:
> Brian,
>
> I'm not sure if you were replying to me or others, but you quoted me and snipped my actual point:
>
> "I'm fine with either more or less frequent releases... I'm not fine with circumventing review or pushing releases outside the ASF."
>
> I agree with everything you said below. I was saying we need to keep the 72h voting window because there are good reasons for it. It's not that everyone has to review - just that everyone has the opportunity to.
>
We're in agreement, except the license allows 3rd parties to produce
forks or binaries so I don't think we need to be concerned about that
possibility. It's not clear to me what the implications for naming are
but that's an entirely separate bike shed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Brett Porter <br...@apache.org>.
Brian,
I'm not sure if you were replying to me or others, but you quoted me and snipped my actual point:
"I'm fine with either more or less frequent releases... I'm not fine with circumventing review or pushing releases outside the ASF."
I agree with everything you said below. I was saying we need to keep the 72h voting window because there are good reasons for it. It's not that everyone has to review - just that everyone has the opportunity to.
- Brett
On 28/11/2009, at 1:40 AM, Brian Fox wrote:
>> I'm also not pushing for duration for "testing" purposes. That's part of it, but as Jason said
>> automation can reduce the need over time (though it's never going to be 100% so there's some value
>> in testing). However, it is mostly for an opportunity to review changes. If we do "8 releases a day",
>
> 8 releases a day or even 2 a day is just a straw man setup to refute
> the speed of releases. Noone is really going to do that at Apache
> because it's pointless, so it's pointless to even discuss it.
>
> If the releases are coming out too fast for you, don't test them if
> you don't want. The rules say at least 3 PMC must vote, but it most
> certainly does not say ALL PMCs must vote on every release. I haven't
> had time to look at every one so I haven't voted. I only vote on
> things I've checked out and that's what every PMC member has the
> responsibility to do. The Apache requirements state that we need to
> validate the basics like license, buildability of the source bundle
> etc. It does not mean we have to manually QA every bit, although
> generally people do make sure it does in fact work. All these things
> can be automated, and they will be shortly on r.a.o. If that satisfies
> your criteria, then you can use that to vote. The rules don't say
> exactly how you have to make up your mind, it's up to you.
>
> I'm actually surprised that people are complaining about weekly
> releases. If I thought it was worth the time, I could find hundreds of
> requests to release faster. Sheesh.
>
> --Brian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Brian Fox <br...@infinity.nu>.
> I'm also not pushing for duration for "testing" purposes. That's part of it, but as Jason said
>automation can reduce the need over time (though it's never going to be 100% so there's some value
>in testing). However, it is mostly for an opportunity to review changes. If we do "8 releases a day",
8 releases a day or even 2 a day is just a straw man setup to refute
the speed of releases. Noone is really going to do that at Apache
because it's pointless, so it's pointless to even discuss it.
If the releases are coming out too fast for you, don't test them if
you don't want. The rules say at least 3 PMC must vote, but it most
certainly does not say ALL PMCs must vote on every release. I haven't
had time to look at every one so I haven't voted. I only vote on
things I've checked out and that's what every PMC member has the
responsibility to do. The Apache requirements state that we need to
validate the basics like license, buildability of the source bundle
etc. It does not mean we have to manually QA every bit, although
generally people do make sure it does in fact work. All these things
can be automated, and they will be shortly on r.a.o. If that satisfies
your criteria, then you can use that to vote. The rules don't say
exactly how you have to make up your mind, it's up to you.
I'm actually surprised that people are complaining about weekly
releases. If I thought it was worth the time, I could find hundreds of
requests to release faster. Sheesh.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Brett Porter <br...@apache.org>.
On 27/11/2009, at 2:27 AM, Todd Thiessen wrote:
>> The logic here is flawed because it is from a single
>> perspective of an
>> individual who finds it burdensome to validate each and every release.
>
> It isn't just me. Both Paul and Brett expressed similar concerns ;-).
I don't think this was my point. I'm fine with either more or less frequent releases (just not as infrequent as 2.0 -> 3.0-alpha-1 or 3.0-alpha-2 -> 3.0-alpha-3 :) I'm not fine with circumventing review or pushing releases outside the ASF.
I'm also not pushing for duration for "testing" purposes. That's part of it, but as Jason said automation can reduce the need over time (though it's never going to be 100% so there's some value in testing). However, it is mostly for an opportunity to review changes. If we do "8 releases a day", then the chances of something undesirable slipping in that others might have noticed increases greatly. We've had things go into actual releases that can do bad things to the remote repo that we may need to live with forever, so it's not unthinkable that such things would be more common under more frequent releases. Sadly, I think the review aspect is frequently lost as people +1 releases they haven't looked at the code changes for, and sometimes haven't even tested.
I actually think frequent releases during alphas is less important than frequent releases after final (3.0.1, 3.0.2, etc). Those consuming the alphas are going to be much more bleeding edge and happy with nightlies / source code. We just need regular milestones for those that have come to depend on it like Archiva, or Tycho as Jason mentioned.
So, in summary - ain't broke, don't fix it :)
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Jason van Zyl <ja...@maven.org>.
On 2009-11-26, at 10:27 AM, Todd Thiessen wrote:
>> The logic here is flawed because it is from a single
>> perspective of an
>> individual who finds it burdensome to validate each and every
>> release.
>
> It isn't just me. Both Paul and Brett expressed similar concerns ;-).
>
That's fine don't look at them, it's pretty simple.
> To keep this short, I simply disagree with Jason's assertion that a
> fix
> should be synonymous with a release. We could go on ad-nauseam but I
> think we both have more important things to do ;-). If I ever get more
> involved with Maven development (which I have really wanted to do, but
> corporate policies get in the way) I may bring it up again. But until
> then I will just bite my tongue as I realize my opinion carries very
> littie weight ;-).
>
>>
>> The value of releasing everyday if there is a fix is because
>> that fix
>> may be very valuable to a user.
>>
>> I pushed extremely aggressively against Benjamin and Igor to put in
>> place the regression test suite and performance framework so that we
>> don't have to fear validation for the most part. I'm
>> confident at this
>> point that we're going to find the problems before any of you do 95%
>> of the time. This is how it should be. When we have a fix it
>> should be
>> made immediately available in a consumable form by the
>> general public
>> because it probably matters to someone. We are at this point
>> responding to people taking the time to accurate report
>> errors. If you
>> watch the process that happens it usually a matter of hours before
>> Benjamin fixes it.
>>
>> The release process here is entirely broken from a users
>> perspective,
>> but that's the Apache Way. Here people think developers are more
>> important then users which is why we have the contorted set of
>> practices we have here now. The work needs to be instantly validated
>> and we can do that now, and once that criterion is met it should be
>> released. This is not the case with many of our plugins which
>> can have
>> a dire impact on users because the tests for critical plugins that
>> just haven't gotten the attention they need yet. I plan to help try
>> and fix this as well but there's only so much that can be done at a
>> time.
>>
>> These are alphas and getting them out as soon as the rules
>> allow here
>> is important for people trying to evaluate 3.x.
>>
>>> ---
>>> Todd Thiessen
>>>
>>>
>>>> -----Original Message-----
>>>> From: paulus.benedictus@gmail.com
>>>> [mailto:paulus.benedictus@gmail.com] On Behalf Of Paul Benedict
>>>> Sent: Wednesday, November 25, 2009 9:21 PM
>>>> To: Maven Developers List
>>>> Subject: Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
>>>>
>>>> I would also like to contribute my frustration with the
>>>> current build process. It's great the alpha releases are
>>>> coming out often, but I cannot possibly be testing them at
>>>> the frequency you guys are currently tagging and voting. I
>>>> thought the "once a week" alpha was a good idea until it
>>>> actually happened. If you guys voted once every three weeks,
>>>> it would be much easier for me to participate. I wonder if
>>>> others believe the same.
>>>>
>>>> Paul
>>>>
>>>> On Wed, Nov 25, 2009 at 7:48 PM, Jason van Zyl
>>>> <ja...@maven.org> wrote:
>>>>> Let's not beat the dead horse. No one cares. There's not
>>>> good reason
>>>>> for not releasing something immediately if there are fixes
>>>> available.
>>>>> That's just not the way it works here, that's fine and not
>>>> a big deal.
>>>>>
>>>>> On 2009-11-25, at 7:52 PM, Brett Porter wrote:
>>>>>
>>>>>>
>>>>>> On 26/11/2009, at 6:24 AM, Jason van Zyl wrote:
>>>>>>
>>>>>>> If ever we really needed to push out builds more
>>>> frequently I would
>>>>>>> just do it from Sonatype. I've given up trying to be
>>>> truly agile at
>>>>>>> Apache, it's just not going to happen.
>>>>>>
>>>>>> I don't understand what the issue is with the current process.
>>>>>> Benjamin is already getting them out faster than the majority of
>>>>>> people will be able to test and review them. Any faster
>>>> and you might
>>>>>> as well just be using the CI builds for whatever purpose
>>>> you have in
>>>>>> mind. You're not going to be able to push out anything
>>>> from Sonatype
>>>>>> that's any more official than those, so what benefit does
>>>> anyone get
>>>>>> from a build that loses the frequency of CI builds and
>>>> loses the benefit of being reviewed before publishing?
>>>>>>
>>>>>> The rules about not promoting snapshots to users are there
>>>> for good
>>>>>> reasons - to make sure the PMC does actually authorize
>>>> releases and
>>>>>> the users know what they are getting, and to encourage
>>>> actually doing
>>>>>> releases (instead of everyone running their own version of
>>>> trunk). I
>>>>>> don't see any upside to a change that loses those. There's
>>>> no problem
>>>>>> pointing individuals to the grid for *testing* purposes as
>>>> far as I
>>>>>> know, as long as they know what they are getting is not a
>>>> release and may not work at all.
>>>>>>
>>>>>> Thanks,
>>>>>> Brett
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>>>>>> additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder, Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> ----------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>>>>> additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>>>> additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Todd Thiessen <th...@nortel.com>.
> The logic here is flawed because it is from a single
> perspective of an
> individual who finds it burdensome to validate each and every release.
It isn't just me. Both Paul and Brett expressed similar concerns ;-).
To keep this short, I simply disagree with Jason's assertion that a fix
should be synonymous with a release. We could go on ad-nauseam but I
think we both have more important things to do ;-). If I ever get more
involved with Maven development (which I have really wanted to do, but
corporate policies get in the way) I may bring it up again. But until
then I will just bite my tongue as I realize my opinion carries very
littie weight ;-).
>
> The value of releasing everyday if there is a fix is because
> that fix
> may be very valuable to a user.
>
> I pushed extremely aggressively against Benjamin and Igor to put in
> place the regression test suite and performance framework so that we
> don't have to fear validation for the most part. I'm
> confident at this
> point that we're going to find the problems before any of you do 95%
> of the time. This is how it should be. When we have a fix it
> should be
> made immediately available in a consumable form by the
> general public
> because it probably matters to someone. We are at this point
> responding to people taking the time to accurate report
> errors. If you
> watch the process that happens it usually a matter of hours before
> Benjamin fixes it.
>
> The release process here is entirely broken from a users
> perspective,
> but that's the Apache Way. Here people think developers are more
> important then users which is why we have the contorted set of
> practices we have here now. The work needs to be instantly validated
> and we can do that now, and once that criterion is met it should be
> released. This is not the case with many of our plugins which
> can have
> a dire impact on users because the tests for critical plugins that
> just haven't gotten the attention they need yet. I plan to help try
> and fix this as well but there's only so much that can be done at a
> time.
>
> These are alphas and getting them out as soon as the rules
> allow here
> is important for people trying to evaluate 3.x.
>
> > ---
> > Todd Thiessen
> >
> >
> >> -----Original Message-----
> >> From: paulus.benedictus@gmail.com
> >> [mailto:paulus.benedictus@gmail.com] On Behalf Of Paul Benedict
> >> Sent: Wednesday, November 25, 2009 9:21 PM
> >> To: Maven Developers List
> >> Subject: Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
> >>
> >> I would also like to contribute my frustration with the
> >> current build process. It's great the alpha releases are
> >> coming out often, but I cannot possibly be testing them at
> >> the frequency you guys are currently tagging and voting. I
> >> thought the "once a week" alpha was a good idea until it
> >> actually happened. If you guys voted once every three weeks,
> >> it would be much easier for me to participate. I wonder if
> >> others believe the same.
> >>
> >> Paul
> >>
> >> On Wed, Nov 25, 2009 at 7:48 PM, Jason van Zyl
> >> <ja...@maven.org> wrote:
> >>> Let's not beat the dead horse. No one cares. There's not
> >> good reason
> >>> for not releasing something immediately if there are fixes
> >> available.
> >>> That's just not the way it works here, that's fine and not
> >> a big deal.
> >>>
> >>> On 2009-11-25, at 7:52 PM, Brett Porter wrote:
> >>>
> >>>>
> >>>> On 26/11/2009, at 6:24 AM, Jason van Zyl wrote:
> >>>>
> >>>>> If ever we really needed to push out builds more
> >> frequently I would
> >>>>> just do it from Sonatype. I've given up trying to be
> >> truly agile at
> >>>>> Apache, it's just not going to happen.
> >>>>
> >>>> I don't understand what the issue is with the current process.
> >>>> Benjamin is already getting them out faster than the majority of
> >>>> people will be able to test and review them. Any faster
> >> and you might
> >>>> as well just be using the CI builds for whatever purpose
> >> you have in
> >>>> mind. You're not going to be able to push out anything
> >> from Sonatype
> >>>> that's any more official than those, so what benefit does
> >> anyone get
> >>>> from a build that loses the frequency of CI builds and
> >> loses the benefit of being reviewed before publishing?
> >>>>
> >>>> The rules about not promoting snapshots to users are there
> >> for good
> >>>> reasons - to make sure the PMC does actually authorize
> >> releases and
> >>>> the users know what they are getting, and to encourage
> >> actually doing
> >>>> releases (instead of everyone running their own version of
> >> trunk). I
> >>>> don't see any upside to a change that loses those. There's
> >> no problem
> >>>> pointing individuals to the grid for *testing* purposes as
> >> far as I
> >>>> know, as long as they know what they are getting is not a
> >> release and may not work at all.
> >>>>
> >>>> Thanks,
> >>>> Brett
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> >>>> additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>
> >>> Thanks,
> >>>
> >>> Jason
> >>>
> >>> ----------------------------------------------------------
> >>> Jason van Zyl
> >>> Founder, Apache Maven
> >>> http://twitter.com/jvanzyl
> >>> ----------------------------------------------------------
> >>>
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> >>> additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> >> additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Jason van Zyl <ja...@maven.org>.
On 2009-11-26, at 11:23 AM, Ralph Goers wrote:
>
> On Nov 26, 2009, at 5:56 AM, Jason van Zyl wrote:
>
>>
>> On 2009-11-26, at 8:04 AM, Todd Thiessen wrote:
>>
>>> I can only speak from experience with what we have done here
>>> internally but I can also attest that releasing too often is a
>>> real pain. You end up having a bunch of releases publicized that
>>> no one cares about. It only serves to clutter a repository and
>>> makes it confusing to consumers wrt which one to use.
>>>
>>> I love the agile model of development but I don't think this
>>> equates to "releasing something immediately if there are fixes
>>> available" as Jason put it. The release needs to be weighed
>>> against the value it provides and the extra time and effort the
>>> community needs to soak and test that release. Agile states that
>>> your software should be releasable at anytime, but it does not
>>> state that it should be continually released.
>>>
>>> Of course, the opposite (ie: not releasing enough) is just as bad
>>> if not worse. Have to find that sweet spot ;-).
>>>
>>
>> The logic here is flawed because it is from a single perspective of
>> an individual who finds it burdensome to validate each and every
>> release.
>
> I don't understand why that logic is flawed. The individual in
> question would be on the Maven PMC and not have time to validate all
> the releases. Asking them to spend their time every week validating
> releases is a bit much.
Hence it being flawed. The automation is going to catch most of the
problems, the ITs and performance framework will do much of what any
PMC member can do building the same applications they work on day in
and day out. All the the users who have things that don't work is who
I want to reach. There is nothing of legal or IP consequence in these
releases and the PMC isn't going to find anything substantial. So it's
generally a waste of time requiring the 72 hours for which most people
just do the same thing they did last time.
>
>>
>> The value of releasing everyday if there is a fix is because that
>> fix may be very valuable to a user.
>
> That value is illusory. The end user is far more likely to get
> pissed off that their Maven version is always out of date. People
> really don't like upgrading all that often. Alphas are a little
> different since end users obviously have some reason that they want
> to test the new functionality, but even there you can't expect them
> to download a release start testing their stuff and before they are
> even done a new release is out.
The value is categorically not illusory. The fixes we been making
along the way have had been useful for people. With the alpha-4 we got
Tycho working properly for a lot of people, and for alpha-5 we fix a
lot of problems with APT (annotations). So you've managed to conflate
what you believe to be useful and what I've found to be useful. Above
I would say is largely your opinion. I have found it different for the
alpha releases.
>
>>
>> I pushed extremely aggressively against Benjamin and Igor to put in
>> place the regression test suite and performance framework so that
>> we don't have to fear validation for the most part. I'm confident
>> at this point that we're going to find the problems before any of
>> you do 95% of the time. This is how it should be. When we have a
>> fix it should be made immediately available in a consumable form by
>> the general public because it probably matters to someone. We are
>> at this point responding to people taking the time to accurate
>> report errors. If you watch the process that happens it usually a
>> matter of hours before Benjamin fixes it.
>
> I have no problem with building in test coverage. More is better.
>
>>
>> The release process here is entirely broken from a users
>> perspective, but that's the Apache Way.
>
> You know, I really dislike it when you throw this nonsense around.
> It gives the board the impression that the Maven community doesn't
> belong at Apache when these sentiments are mostly just yours.
Of course they are my opinions. How can they be construed any other
way. I'm just another developer here right?
> The Apache Way is "community over code". That means sometimes you
> have to do things that are beneficial for the community that may not
> be beneficial to a single individual.
>
The community of users if made up of many individuals so I'm not
exactly sure what your point is.
>> Here people think developers are more important then users which is
>> why we have the contorted set of practices we have here now.
>
> No. The community is more important than a single user. I don't view
> the requirement of having at least 3 PMC members test a release and
> approve it as "contorted".
That's fine, that's your opinion. I happen to have my own. For alphas
having to wait 72 hours for mostly bug fixes to me is dumb. These are
bug fixes specific to users in the community where the validation
performed by anyone is largely not affected by those bugs. Further
with the IT and performance frameworks in place the validation by the
PMC means little. What actually needs to be validated are that the
specific bugs that we've attempted to correct are in fact corrected.
And the only people who can do that are the people we're trying to
help who requested the fixes. They need complete and available builds.
In practice we're finding they don't like to pick them up off the grid.
Again, I don't care. If people want to do alphas every week or two
weeks then that's fine. When I release the shell it will have self-
provisioning capabilities so I probably won't care about releasing any
alphas at that point because the shell will roll itself forward or
back. Then we'll have a good balance. Folks can try every build coming
off the grid if they want from inside the shell and then we can do
monthly releases here if that makes people more comfortable.
>
>> The work needs to be instantly validated and we can do that now,
>> and once that criterion is met it should be released. This is not
>> the case with many of our plugins which can have a dire impact on
>> users because the tests for critical plugins that just haven't
>> gotten the attention they need yet. I plan to help try and fix this
>> as well but there's only so much that can be done at a time.
>>
>> These are alphas and getting them out as soon as the rules allow
>> here is important for people trying to evaluate 3.x.
>
> No one is arguing about getting alphas out quickly. But taking your
> argument to its logical conclusion would imply that a fix is done in
> the morning and a release is performed by lunch. Then another fix is
> done and a release is performed in the afternoon. Or perhaps we have
> 8 releases that day. Where is the value in that?
If each of those fixes something someone reported the value is that it
keeps them actively participating. It's not hard to release 8 times a
day either, the only limit is us.
> The simple fact is that there is a point at which people are
> "comfortable" with releases being made. IMO once a day is too much
> and once a month is way too slow.
>
I'm comfortable releases being made 8 times a day if there are 8
errors found and fixed that day. You're not.
> Ralph
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Ralph Goers <ra...@dslextreme.com>.
On Nov 26, 2009, at 5:56 AM, Jason van Zyl wrote:
>
> On 2009-11-26, at 8:04 AM, Todd Thiessen wrote:
>
>> I can only speak from experience with what we have done here internally but I can also attest that releasing too often is a real pain. You end up having a bunch of releases publicized that no one cares about. It only serves to clutter a repository and makes it confusing to consumers wrt which one to use.
>>
>> I love the agile model of development but I don't think this equates to "releasing something immediately if there are fixes available" as Jason put it. The release needs to be weighed against the value it provides and the extra time and effort the community needs to soak and test that release. Agile states that your software should be releasable at anytime, but it does not state that it should be continually released.
>>
>> Of course, the opposite (ie: not releasing enough) is just as bad if not worse. Have to find that sweet spot ;-).
>>
>
> The logic here is flawed because it is from a single perspective of an individual who finds it burdensome to validate each and every release.
I don't understand why that logic is flawed. The individual in question would be on the Maven PMC and not have time to validate all the releases. Asking them to spend their time every week validating releases is a bit much.
>
> The value of releasing everyday if there is a fix is because that fix may be very valuable to a user.
That value is illusory. The end user is far more likely to get pissed off that their Maven version is always out of date. People really don't like upgrading all that often. Alphas are a little different since end users obviously have some reason that they want to test the new functionality, but even there you can't expect them to download a release start testing their stuff and before they are even done a new release is out.
>
> I pushed extremely aggressively against Benjamin and Igor to put in place the regression test suite and performance framework so that we don't have to fear validation for the most part. I'm confident at this point that we're going to find the problems before any of you do 95% of the time. This is how it should be. When we have a fix it should be made immediately available in a consumable form by the general public because it probably matters to someone. We are at this point responding to people taking the time to accurate report errors. If you watch the process that happens it usually a matter of hours before Benjamin fixes it.
I have no problem with building in test coverage. More is better.
>
> The release process here is entirely broken from a users perspective, but that's the Apache Way.
You know, I really dislike it when you throw this nonsense around. It gives the board the impression that the Maven community doesn't belong at Apache when these sentiments are mostly just yours. The Apache Way is "community over code". That means sometimes you have to do things that are beneficial for the community that may not be beneficial to a single individual.
> Here people think developers are more important then users which is why we have the contorted set of practices we have here now.
No. The community is more important than a single user. I don't view the requirement of having at least 3 PMC members test a release and approve it as "contorted".
> The work needs to be instantly validated and we can do that now, and once that criterion is met it should be released. This is not the case with many of our plugins which can have a dire impact on users because the tests for critical plugins that just haven't gotten the attention they need yet. I plan to help try and fix this as well but there's only so much that can be done at a time.
>
> These are alphas and getting them out as soon as the rules allow here is important for people trying to evaluate 3.x.
No one is arguing about getting alphas out quickly. But taking your argument to its logical conclusion would imply that a fix is done in the morning and a release is performed by lunch. Then another fix is done and a release is performed in the afternoon. Or perhaps we have 8 releases that day. Where is the value in that? The simple fact is that there is a point at which people are "comfortable" with releases being made. IMO once a day is too much and once a month is way too slow.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Jason van Zyl <ja...@maven.org>.
On 2009-11-26, at 8:04 AM, Todd Thiessen wrote:
> I can only speak from experience with what we have done here
> internally but I can also attest that releasing too often is a real
> pain. You end up having a bunch of releases publicized that no one
> cares about. It only serves to clutter a repository and makes it
> confusing to consumers wrt which one to use.
>
> I love the agile model of development but I don't think this equates
> to "releasing something immediately if there are fixes available" as
> Jason put it. The release needs to be weighed against the value it
> provides and the extra time and effort the community needs to soak
> and test that release. Agile states that your software should be
> releasable at anytime, but it does not state that it should be
> continually released.
>
> Of course, the opposite (ie: not releasing enough) is just as bad if
> not worse. Have to find that sweet spot ;-).
>
The logic here is flawed because it is from a single perspective of an
individual who finds it burdensome to validate each and every release.
The value of releasing everyday if there is a fix is because that fix
may be very valuable to a user.
I pushed extremely aggressively against Benjamin and Igor to put in
place the regression test suite and performance framework so that we
don't have to fear validation for the most part. I'm confident at this
point that we're going to find the problems before any of you do 95%
of the time. This is how it should be. When we have a fix it should be
made immediately available in a consumable form by the general public
because it probably matters to someone. We are at this point
responding to people taking the time to accurate report errors. If you
watch the process that happens it usually a matter of hours before
Benjamin fixes it.
The release process here is entirely broken from a users perspective,
but that's the Apache Way. Here people think developers are more
important then users which is why we have the contorted set of
practices we have here now. The work needs to be instantly validated
and we can do that now, and once that criterion is met it should be
released. This is not the case with many of our plugins which can have
a dire impact on users because the tests for critical plugins that
just haven't gotten the attention they need yet. I plan to help try
and fix this as well but there's only so much that can be done at a
time.
These are alphas and getting them out as soon as the rules allow here
is important for people trying to evaluate 3.x.
> ---
> Todd Thiessen
>
>
>> -----Original Message-----
>> From: paulus.benedictus@gmail.com
>> [mailto:paulus.benedictus@gmail.com] On Behalf Of Paul Benedict
>> Sent: Wednesday, November 25, 2009 9:21 PM
>> To: Maven Developers List
>> Subject: Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
>>
>> I would also like to contribute my frustration with the
>> current build process. It's great the alpha releases are
>> coming out often, but I cannot possibly be testing them at
>> the frequency you guys are currently tagging and voting. I
>> thought the "once a week" alpha was a good idea until it
>> actually happened. If you guys voted once every three weeks,
>> it would be much easier for me to participate. I wonder if
>> others believe the same.
>>
>> Paul
>>
>> On Wed, Nov 25, 2009 at 7:48 PM, Jason van Zyl
>> <ja...@maven.org> wrote:
>>> Let's not beat the dead horse. No one cares. There's not
>> good reason
>>> for not releasing something immediately if there are fixes
>> available.
>>> That's just not the way it works here, that's fine and not
>> a big deal.
>>>
>>> On 2009-11-25, at 7:52 PM, Brett Porter wrote:
>>>
>>>>
>>>> On 26/11/2009, at 6:24 AM, Jason van Zyl wrote:
>>>>
>>>>> If ever we really needed to push out builds more
>> frequently I would
>>>>> just do it from Sonatype. I've given up trying to be
>> truly agile at
>>>>> Apache, it's just not going to happen.
>>>>
>>>> I don't understand what the issue is with the current process.
>>>> Benjamin is already getting them out faster than the majority of
>>>> people will be able to test and review them. Any faster
>> and you might
>>>> as well just be using the CI builds for whatever purpose
>> you have in
>>>> mind. You're not going to be able to push out anything
>> from Sonatype
>>>> that's any more official than those, so what benefit does
>> anyone get
>>>> from a build that loses the frequency of CI builds and
>> loses the benefit of being reviewed before publishing?
>>>>
>>>> The rules about not promoting snapshots to users are there
>> for good
>>>> reasons - to make sure the PMC does actually authorize
>> releases and
>>>> the users know what they are getting, and to encourage
>> actually doing
>>>> releases (instead of everyone running their own version of
>> trunk). I
>>>> don't see any upside to a change that loses those. There's
>> no problem
>>>> pointing individuals to the grid for *testing* purposes as
>> far as I
>>>> know, as long as they know what they are getting is not a
>> release and may not work at all.
>>>>
>>>> Thanks,
>>>> Brett
>>>>
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>>>> additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>>> additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>> additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Todd Thiessen <th...@nortel.com>.
I can only speak from experience with what we have done here internally but I can also attest that releasing too often is a real pain. You end up having a bunch of releases publicized that no one cares about. It only serves to clutter a repository and makes it confusing to consumers wrt which one to use.
I love the agile model of development but I don't think this equates to "releasing something immediately if there are fixes available" as Jason put it. The release needs to be weighed against the value it provides and the extra time and effort the community needs to soak and test that release. Agile states that your software should be releasable at anytime, but it does not state that it should be continually released.
Of course, the opposite (ie: not releasing enough) is just as bad if not worse. Have to find that sweet spot ;-).
---
Todd Thiessen
> -----Original Message-----
> From: paulus.benedictus@gmail.com
> [mailto:paulus.benedictus@gmail.com] On Behalf Of Paul Benedict
> Sent: Wednesday, November 25, 2009 9:21 PM
> To: Maven Developers List
> Subject: Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
>
> I would also like to contribute my frustration with the
> current build process. It's great the alpha releases are
> coming out often, but I cannot possibly be testing them at
> the frequency you guys are currently tagging and voting. I
> thought the "once a week" alpha was a good idea until it
> actually happened. If you guys voted once every three weeks,
> it would be much easier for me to participate. I wonder if
> others believe the same.
>
> Paul
>
> On Wed, Nov 25, 2009 at 7:48 PM, Jason van Zyl
> <ja...@maven.org> wrote:
> > Let's not beat the dead horse. No one cares. There's not
> good reason
> > for not releasing something immediately if there are fixes
> available.
> > That's just not the way it works here, that's fine and not
> a big deal.
> >
> > On 2009-11-25, at 7:52 PM, Brett Porter wrote:
> >
> >>
> >> On 26/11/2009, at 6:24 AM, Jason van Zyl wrote:
> >>
> >>> If ever we really needed to push out builds more
> frequently I would
> >>> just do it from Sonatype. I've given up trying to be
> truly agile at
> >>> Apache, it's just not going to happen.
> >>
> >> I don't understand what the issue is with the current process.
> >> Benjamin is already getting them out faster than the majority of
> >> people will be able to test and review them. Any faster
> and you might
> >> as well just be using the CI builds for whatever purpose
> you have in
> >> mind. You're not going to be able to push out anything
> from Sonatype
> >> that's any more official than those, so what benefit does
> anyone get
> >> from a build that loses the frequency of CI builds and
> loses the benefit of being reviewed before publishing?
> >>
> >> The rules about not promoting snapshots to users are there
> for good
> >> reasons - to make sure the PMC does actually authorize
> releases and
> >> the users know what they are getting, and to encourage
> actually doing
> >> releases (instead of everyone running their own version of
> trunk). I
> >> don't see any upside to a change that loses those. There's
> no problem
> >> pointing individuals to the grid for *testing* purposes as
> far as I
> >> know, as long as they know what they are getting is not a
> release and may not work at all.
> >>
> >> Thanks,
> >> Brett
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> >> additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > ----------------------------------------------------------
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Paul Benedict <pb...@apache.org>.
I would also like to contribute my frustration with the current build
process. It's great the alpha releases are coming out often, but I
cannot possibly be testing them at the frequency you guys are
currently tagging and voting. I thought the "once a week" alpha was a
good idea until it actually happened. If you guys voted once every
three weeks, it would be much easier for me to participate. I wonder
if others believe the same.
Paul
On Wed, Nov 25, 2009 at 7:48 PM, Jason van Zyl <ja...@maven.org> wrote:
> Let's not beat the dead horse. No one cares. There's not good reason for not
> releasing something immediately if there are fixes available. That's just
> not the way it works here, that's fine and not a big deal.
>
> On 2009-11-25, at 7:52 PM, Brett Porter wrote:
>
>>
>> On 26/11/2009, at 6:24 AM, Jason van Zyl wrote:
>>
>>> If ever we really needed to push out builds more frequently I would just
>>> do it from Sonatype. I've given up trying to be truly agile at Apache, it's
>>> just not going to happen.
>>
>> I don't understand what the issue is with the current process. Benjamin is
>> already getting them out faster than the majority of people will be able to
>> test and review them. Any faster and you might as well just be using the CI
>> builds for whatever purpose you have in mind. You're not going to be able to
>> push out anything from Sonatype that's any more official than those, so what
>> benefit does anyone get from a build that loses the frequency of CI builds
>> and loses the benefit of being reviewed before publishing?
>>
>> The rules about not promoting snapshots to users are there for good
>> reasons - to make sure the PMC does actually authorize releases and the
>> users know what they are getting, and to encourage actually doing releases
>> (instead of everyone running their own version of trunk). I don't see any
>> upside to a change that loses those. There's no problem pointing individuals
>> to the grid for *testing* purposes as far as I know, as long as they know
>> what they are getting is not a release and may not work at all.
>>
>> Thanks,
>> Brett
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Jason van Zyl <ja...@maven.org>.
Let's not beat the dead horse. No one cares. There's not good reason
for not releasing something immediately if there are fixes available.
That's just not the way it works here, that's fine and not a big deal.
On 2009-11-25, at 7:52 PM, Brett Porter wrote:
>
> On 26/11/2009, at 6:24 AM, Jason van Zyl wrote:
>
>> If ever we really needed to push out builds more frequently I would
>> just do it from Sonatype. I've given up trying to be truly agile at
>> Apache, it's just not going to happen.
>
> I don't understand what the issue is with the current process.
> Benjamin is already getting them out faster than the majority of
> people will be able to test and review them. Any faster and you
> might as well just be using the CI builds for whatever purpose you
> have in mind. You're not going to be able to push out anything from
> Sonatype that's any more official than those, so what benefit does
> anyone get from a build that loses the frequency of CI builds and
> loses the benefit of being reviewed before publishing?
>
> The rules about not promoting snapshots to users are there for good
> reasons - to make sure the PMC does actually authorize releases and
> the users know what they are getting, and to encourage actually
> doing releases (instead of everyone running their own version of
> trunk). I don't see any upside to a change that loses those. There's
> no problem pointing individuals to the grid for *testing* purposes
> as far as I know, as long as they know what they are getting is not
> a release and may not work at all.
>
> Thanks,
> Brett
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Brett Porter <br...@apache.org>.
On 26/11/2009, at 6:24 AM, Jason van Zyl wrote:
> If ever we really needed to push out builds more frequently I would just do it from Sonatype. I've given up trying to be truly agile at Apache, it's just not going to happen.
I don't understand what the issue is with the current process. Benjamin is already getting them out faster than the majority of people will be able to test and review them. Any faster and you might as well just be using the CI builds for whatever purpose you have in mind. You're not going to be able to push out anything from Sonatype that's any more official than those, so what benefit does anyone get from a build that loses the frequency of CI builds and loses the benefit of being reviewed before publishing?
The rules about not promoting snapshots to users are there for good reasons - to make sure the PMC does actually authorize releases and the users know what they are getting, and to encourage actually doing releases (instead of everyone running their own version of trunk). I don't see any upside to a change that loses those. There's no problem pointing individuals to the grid for *testing* purposes as far as I know, as long as they know what they are getting is not a release and may not work at all.
Thanks,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Jason van Zyl <ja...@maven.org>.
If ever we really needed to push out builds more frequently I would
just do it from Sonatype. I've given up trying to be truly agile at
Apache, it's just not going to happen.
On 2009-11-25, at 2:10 PM, Dan Fabulich wrote:
> Niall Pemberton wrote:
>
>> On Mon, Nov 23, 2009 at 7:59 PM, Paul Gier <pg...@redhat.com> wrote:
>>> I wonder if we really need a full vote for every alpha.
>>> Especially if this
>>> is going to happen every two weeks. Why not just vote for a 2
>>> week alpha
>>> release schedule and then don't do another vote until it's time
>>> for beta 1?
>>
>> The ASF requires a vote on the artifacts being released. You can't
>> just sign a blank cheque for any future release. On that basis
>> someone could put something that isn't allowed (e.g. a copy of some
>> GPL code) into maven and then just cut an alpha release.
>>
>> I tried to find something in the ASF docs, but the release FAQ only
>> says "Each PMC must obey the ASF requirements on approving any
>> release" - but I can't find something that specifically says what
>> the "requirements on approving any release" are.
>>
>> http://www.apache.org/dev/release.html
>
> That's written up under http://www.apache.org/foundation/voting.html
>
> Adding a link to the voting doc from the release doc would probably
> be wise, but it's always a huge mess when somebody tries to modify
> release.html :-)
>
> -Dan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Dan Fabulich <da...@fabulich.com>.
Niall Pemberton wrote:
> On Mon, Nov 23, 2009 at 7:59 PM, Paul Gier <pg...@redhat.com> wrote:
>> I wonder if we really need a full vote for every alpha. Especially if this
>> is going to happen every two weeks. Why not just vote for a 2 week alpha
>> release schedule and then don't do another vote until it's time for beta 1?
>
> The ASF requires a vote on the artifacts being released. You can't just
> sign a blank cheque for any future release. On that basis someone could
> put something that isn't allowed (e.g. a copy of some GPL code) into
> maven and then just cut an alpha release.
>
> I tried to find something in the ASF docs, but the release FAQ only says
> "Each PMC must obey the ASF requirements on approving any release" - but
> I can't find something that specifically says what the "requirements on
> approving any release" are.
>
> http://www.apache.org/dev/release.html
That's written up under http://www.apache.org/foundation/voting.html
Adding a link to the voting doc from the release doc would probably be
wise, but it's always a huge mess when somebody tries to modify
release.html :-)
-Dan
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Niall Pemberton <ni...@gmail.com>.
On Mon, Nov 23, 2009 at 7:59 PM, Paul Gier <pg...@redhat.com> wrote:
> I wonder if we really need a full vote for every alpha. Especially if this
> is going to happen every two weeks. Why not just vote for a 2 week alpha
> release schedule and then don't do another vote until it's time for beta 1?
The ASF requires a vote on the artifacts being released. You can't
just sign a blank cheque for any future release. On that basis someone
could put something that isn't allowed (e.g. a copy of some GPL code)
into maven and then just cut an alpha release.
I tried to find something in the ASF docs, but the release FAQ only
says "Each PMC must obey the ASF requirements on approving any
release" - but I can't find something that specifically says what the
"requirements on approving any release" are.
http://www.apache.org/dev/release.html
Niall
> Benjamin Bentmann wrote:
>>
>> Hi,
>>
>> We solved some more issues:
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14952
>>
>> There are still a couple of issues left in JIRA:
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-018/
>>
>> Staged source and binary distros:
>>
>> https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> +1 from me
>>
>>
>> Benjamim
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Paul Gier <pg...@redhat.com>.
I wonder if we really need a full vote for every alpha. Especially if this is
going to happen every two weeks. Why not just vote for a 2 week alpha release
schedule and then don't do another vote until it's time for beta 1?
Benjamin Bentmann wrote:
> Hi,
>
> We solved some more issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14952
>
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
>
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-018/
>
> Staged source and binary distros:
> https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
>
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> +1 from me
>
>
> Benjamim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Brian Fox <br...@infinity.nu>.
On Fri, Dec 4, 2009 at 2:16 AM, Jorg Heymans <jo...@gmail.com> wrote:
> On Thu, Dec 3, 2009 at 7:44 PM, Brian Fox <br...@infinity.nu> wrote:
>> Something like duplicate dependencies likely means you have a real
>> problem you didn't know about in your poms. I think failing is
>> appropriate in this case.
>
> I fail to grok what you just said there. So if i have in my pom
>
> <dependency>
> <groupId>javax.persistence</groupId>
> <artifactId>persistence-api</artifactId>
> <version>1.0</version>
> </dependency>
>
> and then 25 other dependencies and then again the one above (due to a
> copy-paste oversight let's say) then I have a real problem in my build
> you say. How is it different from unused and declared dependencies, or
> used and undeclared ?
Yes that is a problem because if you later go to upgrade to 1.2,
you're most likely going to find the first instance and change it, but
you're still going to get 1.0 because last time I checked, it was last
wins. This is a hidden cancer in your pom that will bite you later.
How is it different than undeclared dependencies? It's slightly worse
because you have a false sense of security by having it specified.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Jorg Heymans <jo...@gmail.com>.
On Thu, Dec 3, 2009 at 7:44 PM, Brian Fox <br...@infinity.nu> wrote:
> Something like duplicate dependencies likely means you have a real
> problem you didn't know about in your poms. I think failing is
> appropriate in this case.
I fail to grok what you just said there. So if i have in my pom
<dependency>
<groupId>javax.persistence</groupId>
<artifactId>persistence-api</artifactId>
<version>1.0</version>
</dependency>
and then 25 other dependencies and then again the one above (due to a
copy-paste oversight let's say) then I have a real problem in my build
you say. How is it different from unused and declared dependencies, or
used and undeclared ? For me these all fit in the same boat ie
'potential build optimizations'
Jorg
PS how about a dependency:scan-duplicates then ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Brian Fox <br...@infinity.nu>.
Something like duplicate dependencies likely means you have a real
problem you didn't know about in your poms. I think failing is
appropriate in this case.
On Thu, Dec 3, 2009 at 5:42 AM, Stephen Connolly
<st...@gmail.com> wrote:
> 2009/12/3 Stephen Connolly <st...@gmail.com>
>
>>
>>
>> 2009/12/3 Jorg Heymans <jo...@gmail.com>
>>
>>> On Thu, Dec 3, 2009 at 11:10 AM, Stephen Connolly
>>> <st...@gmail.com> wrote:
>>> > 2009/12/3 Jorg Heymans <jo...@gmail.com>
>>> >
>>> >> On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann
>>> >> <be...@udo.edu> wrote:
>>> >> > Jorg Heymans wrote:
>>> >> >
>>> >> >> [ERROR] The project build-tools:1-SNAPSHOT
>>> >> >> (D:\src\myproject\pom.xml) has 1 error
>>> >> >> [ERROR]
>>> >> >>
>>> >>
>>> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>>> >> >> must be unique: junit:junit:jar -> duplicate declaration of version
>>> >> >> 3.8.2
>>> >> >>
>>> >> >> Shall i log an issue for this or is this a known feature ?
>>> >> >
>>> >> > The error itself is by design and is part of overall stricter POM
>>> >> > validation. If the cause isn't present in the current POM, it must be
>>> >> > present in one of its parents. "mvn ... -e" should tell more but I
>>> will
>>> >> look
>>> >> > into improving the message for the next release.
>>> >>
>>> >> I can understand the need for stricter pom validation, but is it
>>> >> really necessary to fail a build completely just because a dependency
>>> >> is declared twice ? It seems a bit harsh.
>>> >
>>> >
>>> > Actually, I'm liking this build failing on double dependencies.
>>>
>>> Any particular reason or do you get a kick out of scanning 60+ module
>>> reactor builds for duplicates ? :-P
>>>
>>
>> I've got most of my projects down to no duplicates... the error stops it
>> happening again!
>>
>> Perhaps we should have 2.2.2 start issuing the warning though! Or maybe a
>> CLI option for 3.0 such as --no-strict-pom-validation
>>
>
> actually much better is something like
>
> --yes-i-am-a-bold-developer-and-i-know-i-should-remove-duplicate-dependencies-but-give-me-a-break
>
> that way you're _encouraged_ to fix it fast
>
> ;-)
>
>
>>
>>
>>>
>>> Jorg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Stephen Connolly <st...@gmail.com>.
2009/12/3 Stephen Connolly <st...@gmail.com>
>
>
> 2009/12/3 Jorg Heymans <jo...@gmail.com>
>
>> On Thu, Dec 3, 2009 at 11:10 AM, Stephen Connolly
>> <st...@gmail.com> wrote:
>> > 2009/12/3 Jorg Heymans <jo...@gmail.com>
>> >
>> >> On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann
>> >> <be...@udo.edu> wrote:
>> >> > Jorg Heymans wrote:
>> >> >
>> >> >> [ERROR] The project build-tools:1-SNAPSHOT
>> >> >> (D:\src\myproject\pom.xml) has 1 error
>> >> >> [ERROR]
>> >> >>
>> >>
>> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>> >> >> must be unique: junit:junit:jar -> duplicate declaration of version
>> >> >> 3.8.2
>> >> >>
>> >> >> Shall i log an issue for this or is this a known feature ?
>> >> >
>> >> > The error itself is by design and is part of overall stricter POM
>> >> > validation. If the cause isn't present in the current POM, it must be
>> >> > present in one of its parents. "mvn ... -e" should tell more but I
>> will
>> >> look
>> >> > into improving the message for the next release.
>> >>
>> >> I can understand the need for stricter pom validation, but is it
>> >> really necessary to fail a build completely just because a dependency
>> >> is declared twice ? It seems a bit harsh.
>> >
>> >
>> > Actually, I'm liking this build failing on double dependencies.
>>
>> Any particular reason or do you get a kick out of scanning 60+ module
>> reactor builds for duplicates ? :-P
>>
>
> I've got most of my projects down to no duplicates... the error stops it
> happening again!
>
> Perhaps we should have 2.2.2 start issuing the warning though! Or maybe a
> CLI option for 3.0 such as --no-strict-pom-validation
>
actually much better is something like
--yes-i-am-a-bold-developer-and-i-know-i-should-remove-duplicate-dependencies-but-give-me-a-break
that way you're _encouraged_ to fix it fast
;-)
>
>
>>
>> Jorg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Stephen Connolly <st...@gmail.com>.
2009/12/3 Jorg Heymans <jo...@gmail.com>
> On Thu, Dec 3, 2009 at 11:10 AM, Stephen Connolly
> <st...@gmail.com> wrote:
> > 2009/12/3 Jorg Heymans <jo...@gmail.com>
> >
> >> On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann
> >> <be...@udo.edu> wrote:
> >> > Jorg Heymans wrote:
> >> >
> >> >> [ERROR] The project build-tools:1-SNAPSHOT
> >> >> (D:\src\myproject\pom.xml) has 1 error
> >> >> [ERROR]
> >> >>
> >>
> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
> >> >> must be unique: junit:junit:jar -> duplicate declaration of version
> >> >> 3.8.2
> >> >>
> >> >> Shall i log an issue for this or is this a known feature ?
> >> >
> >> > The error itself is by design and is part of overall stricter POM
> >> > validation. If the cause isn't present in the current POM, it must be
> >> > present in one of its parents. "mvn ... -e" should tell more but I
> will
> >> look
> >> > into improving the message for the next release.
> >>
> >> I can understand the need for stricter pom validation, but is it
> >> really necessary to fail a build completely just because a dependency
> >> is declared twice ? It seems a bit harsh.
> >
> >
> > Actually, I'm liking this build failing on double dependencies.
>
> Any particular reason or do you get a kick out of scanning 60+ module
> reactor builds for duplicates ? :-P
>
I've got most of my projects down to no duplicates... the error stops it
happening again!
Perhaps we should have 2.2.2 start issuing the warning though! Or maybe a
CLI option for 3.0 such as --no-strict-pom-validation
>
> Jorg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Jorg Heymans <jo...@gmail.com>.
On Thu, Dec 3, 2009 at 11:10 AM, Stephen Connolly
<st...@gmail.com> wrote:
> 2009/12/3 Jorg Heymans <jo...@gmail.com>
>
>> On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann
>> <be...@udo.edu> wrote:
>> > Jorg Heymans wrote:
>> >
>> >> [ERROR] The project build-tools:1-SNAPSHOT
>> >> (D:\src\myproject\pom.xml) has 1 error
>> >> [ERROR]
>> >>
>> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>> >> must be unique: junit:junit:jar -> duplicate declaration of version
>> >> 3.8.2
>> >>
>> >> Shall i log an issue for this or is this a known feature ?
>> >
>> > The error itself is by design and is part of overall stricter POM
>> > validation. If the cause isn't present in the current POM, it must be
>> > present in one of its parents. "mvn ... -e" should tell more but I will
>> look
>> > into improving the message for the next release.
>>
>> I can understand the need for stricter pom validation, but is it
>> really necessary to fail a build completely just because a dependency
>> is declared twice ? It seems a bit harsh.
>
>
> Actually, I'm liking this build failing on double dependencies.
Any particular reason or do you get a kick out of scanning 60+ module
reactor builds for duplicates ? :-P
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Stephen Connolly <st...@gmail.com>.
2009/12/3 Jorg Heymans <jo...@gmail.com>
> On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann
> <be...@udo.edu> wrote:
> > Jorg Heymans wrote:
> >
> >> [ERROR] The project build-tools:1-SNAPSHOT
> >> (D:\src\myproject\pom.xml) has 1 error
> >> [ERROR]
> >>
> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
> >> must be unique: junit:junit:jar -> duplicate declaration of version
> >> 3.8.2
> >>
> >> Shall i log an issue for this or is this a known feature ?
> >
> > The error itself is by design and is part of overall stricter POM
> > validation. If the cause isn't present in the current POM, it must be
> > present in one of its parents. "mvn ... -e" should tell more but I will
> look
> > into improving the message for the next release.
>
> I can understand the need for stricter pom validation, but is it
> really necessary to fail a build completely just because a dependency
> is declared twice ? It seems a bit harsh.
Actually, I'm liking this build failing on double dependencies.
> A big [WARNING] seems more
> appropriate. Will m3 also fail builds for this one then: [WARNING]
> Using platform encoding (Cp1252 actually) to copy filtered resources,
> i.e. build is platform dependent!
>
> IMO most knowledgeable people react on warnings more positive, so more
> like "ah cool m3 spotted a potential hazard so lets go and fix this"
> instead of "why the heck is m3 not able to build my project, lets
> revert to m2". Debatable, but that's how i see it.
>
> Cheers,
> Jorg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Jorg Heymans <jo...@gmail.com>.
On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann
<be...@udo.edu> wrote:
> Jorg Heymans wrote:
>
>> [ERROR] The project build-tools:1-SNAPSHOT
>> (D:\src\myproject\pom.xml) has 1 error
>> [ERROR]
>> 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
>> must be unique: junit:junit:jar -> duplicate declaration of version
>> 3.8.2
>>
>> Shall i log an issue for this or is this a known feature ?
>
> The error itself is by design and is part of overall stricter POM
> validation. If the cause isn't present in the current POM, it must be
> present in one of its parents. "mvn ... -e" should tell more but I will look
> into improving the message for the next release.
I can understand the need for stricter pom validation, but is it
really necessary to fail a build completely just because a dependency
is declared twice ? It seems a bit harsh. A big [WARNING] seems more
appropriate. Will m3 also fail builds for this one then: [WARNING]
Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
IMO most knowledgeable people react on warnings more positive, so more
like "ah cool m3 spotted a potential hazard so lets go and fix this"
instead of "why the heck is m3 not able to build my project, lets
revert to m2". Debatable, but that's how i see it.
Cheers,
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Benjamin Bentmann <be...@udo.edu>.
Jorg Heymans wrote:
> [ERROR] The project build-tools:1-SNAPSHOT
> (D:\src\myproject\pom.xml) has 1 error
> [ERROR] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
> must be unique: junit:junit:jar -> duplicate declaration of version
> 3.8.2
>
> Shall i log an issue for this or is this a known feature ?
The error itself is by design and is part of overall stricter POM
validation. If the cause isn't present in the current POM, it must be
present in one of its parents. "mvn ... -e" should tell more but I will
look into improving the message for the next release.
> [...] lots of "expression
> ${pom.version} is deprecated. Please use ${project.version} instead",
> wierd thing is i'm never actually using expressions in my project.
As said, likely due to one of the parents from which you inherit.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Jorg Heymans <jo...@gmail.com>.
Tried it out on our project, and i'm getting this:
[ERROR] The project build-tools:1-SNAPSHOT
(D:\src\myproject\pom.xml) has 1 error
[ERROR] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: junit:junit:jar -> duplicate declaration of version
3.8.2
I can understand what this is trying to say, but the pom in question
is only a module pom that has no dependencies declared:
<parent>
<groupId>my.group</groupId>
<artifactId>parent</artifactId>
<version>19-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>build-tools</artifactId>
<packaging>pom</packaging>
<version>1-SNAPSHOT</version>
<modules>
<module>ant</module>
<module>maven</module>
</modules>
Shall i log an issue for this or is this a known feature ? The output
of -e does not reveal anything useful besides lots of "expression
${pom.version} is deprecated. Please use ${project.version} instead",
wierd thing is i'm never actually using expressions in my project.
Jorg
On Mon, Nov 23, 2009 at 11:04 PM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> +1
>
> --
> Regards,
> Igor
>
> Benjamin Bentmann wrote:
>>
>> Hi,
>>
>> We solved some more issues:
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14952
>>
>> There are still a couple of issues left in JIRA:
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-018/
>>
>> Staged source and binary distros:
>>
>> https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> +1 from me
>>
>>
>> Benjamim
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
+1
--
Regards,
Igor
Benjamin Bentmann wrote:
> Hi,
>
> We solved some more issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14952
>
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
>
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-018/
>
> Staged source and binary distros:
> https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
>
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> +1 from me
>
>
> Benjamim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Stephen Connolly <st...@gmail.com>.
+1
2009/11/23 nicolas de loof <ni...@gmail.com>:
> +1
>
> 2009/11/23 Arnaud HERITIER <ah...@gmail.com>
>
>> +1
>>
>> Arnaud Héritier
>> Software Factory Manager
>> eXo platform - http://www.exoplatform.com
>> ---
>> http://www.aheritier.net
>>
>>
>> On Mon, Nov 23, 2009 at 5:38 PM, Jason van Zyl <ja...@maven.org> wrote:
>>
>> > +1
>> >
>> >
>> > On 2009-11-23, at 11:33 AM, Benjamin Bentmann wrote:
>> >
>> > Hi,
>> >>
>> >> We solved some more issues:
>> >>
>> >>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14952
>> >>
>> >> There are still a couple of issues left in JIRA:
>> >>
>> >>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
>> >>
>> >> Staging repo:
>> >> https://repository.apache.org/content/repositories/maven-018/
>> >>
>> >> Staged source and binary distros:
>> >>
>> >>
>> https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
>> >>
>> >> Guide to testing staged releases:
>> >> http://maven.apache.org/guides/development/guide-testing-releases.html
>> >>
>> >> Vote open for 72 hours.
>> >>
>> >> [ ] +1
>> >> [ ] +0
>> >> [ ] -1
>> >>
>> >> +1 from me
>> >>
>> >>
>> >> Benjamim
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> > Thanks,
>> >
>> > Jason
>> >
>> > ----------------------------------------------------------
>> > Jason van Zyl
>> > Founder, Apache Maven
>> > http://twitter.com/jvanzyl
>> > ----------------------------------------------------------
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by nicolas de loof <ni...@gmail.com>.
+1
2009/11/23 Arnaud HERITIER <ah...@gmail.com>
> +1
>
> Arnaud Héritier
> Software Factory Manager
> eXo platform - http://www.exoplatform.com
> ---
> http://www.aheritier.net
>
>
> On Mon, Nov 23, 2009 at 5:38 PM, Jason van Zyl <ja...@maven.org> wrote:
>
> > +1
> >
> >
> > On 2009-11-23, at 11:33 AM, Benjamin Bentmann wrote:
> >
> > Hi,
> >>
> >> We solved some more issues:
> >>
> >>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14952
> >>
> >> There are still a couple of issues left in JIRA:
> >>
> >>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
> >>
> >> Staging repo:
> >> https://repository.apache.org/content/repositories/maven-018/
> >>
> >> Staged source and binary distros:
> >>
> >>
> https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
> >>
> >> Guide to testing staged releases:
> >> http://maven.apache.org/guides/development/guide-testing-releases.html
> >>
> >> Vote open for 72 hours.
> >>
> >> [ ] +1
> >> [ ] +0
> >> [ ] -1
> >>
> >> +1 from me
> >>
> >>
> >> Benjamim
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > ----------------------------------------------------------
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Arnaud HERITIER <ah...@gmail.com>.
+1
Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net
On Mon, Nov 23, 2009 at 5:38 PM, Jason van Zyl <ja...@maven.org> wrote:
> +1
>
>
> On 2009-11-23, at 11:33 AM, Benjamin Bentmann wrote:
>
> Hi,
>>
>> We solved some more issues:
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14952
>>
>> There are still a couple of issues left in JIRA:
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-018/
>>
>> Staged source and binary distros:
>>
>> https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> +1 from me
>>
>>
>> Benjamim
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Jason van Zyl <ja...@maven.org>.
+1
On 2009-11-23, at 11:33 AM, Benjamin Bentmann wrote:
> Hi,
>
> We solved some more issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=14952
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-018/
>
> Staged source and binary distros:
> https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> +1 from me
>
>
> Benjamim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[RESULT] [VOTE] Release Apache Maven 3.0-alpha-5
Posted by Benjamin Bentmann <be...@udo.edu>.
Hi,
The vote has passed with the following result:
+1 (binding): Benjamin Bentmann, Jason van Zyl, Arnaud Héritier, Olivier
Lamy
+1 (non-binding): Nicolas De Loof, Stephen Connolly, Igor Fedorenko
I will promote the artifacts to the central repository and continue with
the release.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org