You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@tesla.io> on 2013/09/14 19:24:52 UTC
Leaving Maven Core POMs at major.minor-SNAPSHOT
When a release fails like this it is annoying to have to rev back the version of the POM. I'm not sure who flipped the versions in the POM and while it's a little more visible to see what you're moving toward I prefer the pattern of:
3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
I know this may not be obvious to the casual observer as they may think 3.1 is next, but I'm personally fine with that.
Especially after a failed release because then I don't have to go change all the POMs (whether rolling back manually, using the release rollback, the version:set command, or whatever else). It's much easier to just fix what's necessary and carry on.
Unless anyone objects I would like to go back this pattern, what I previously had, because it's far easier to manage. Ideally it might be nice if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu of that I would prefer not to diddle POMs after a failed release.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Jason van Zyl <ja...@tesla.io>.
We can certainly move in that direction, nothing is currently setup for this.
On Sep 14, 2013, at 1:29 PM, Fred Cooke <fr...@gmail.com> wrote:
> You're in Git now. You don't *have* to push your tag and release commits up
> to the public world until AFTER you've checked they're OK. Or by failed
> release do you mean voted down? They could live on branches until set in
> stone, then merge --ff-only into master at that point, if so.
>
>
> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
>> When a release fails like this it is annoying to have to rev back the
>> version of the POM. I'm not sure who flipped the versions in the POM and
>> while it's a little more visible to see what you're moving toward I prefer
>> the pattern of:
>>
>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>>
>> I know this may not be obvious to the casual observer as they may think
>> 3.1 is next, but I'm personally fine with that.
>>
>> Especially after a failed release because then I don't have to go change
>> all the POMs (whether rolling back manually, using the release rollback,
>> the version:set command, or whatever else). It's much easier to just fix
>> what's necessary and carry on.
>>
>> Unless anyone objects I would like to go back this pattern, what I
>> previously had, because it's far easier to manage. Ideally it might be nice
>> if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu of
>> that I would prefer not to diddle POMs after a failed release.
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Robert Scholte <rf...@apache.org>.
Interesting usecase for http://jira.codehaus.org/browse/MRELEASE-431
So even though 3.1-SNAPSHOT is before 3.1.1 I can imagine why this
practice would work.
btw, for the m-release-p there's no need to change the version back to
3.1.1-SNAPSHOT before a re-release of 3.1.1
Robert
Op Sat, 14 Sep 2013 20:20:55 +0200 schreef Mark Struberg
<st...@yahoo.de>:
> +1, that's what we also use in DeltaSpike and dozen other projects.
> pushChanges=false + localCheckout=true for the win!
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Arnaud Héritier <ah...@gmail.com>
>> To: Maven Developers List <de...@maven.apache.org>
>> Cc:
>> Sent: Saturday, 14 September 2013, 19:45
>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>
>> G ood practice too. I'm using it also at work and we are doing our
>> releases on dedicated branches.
>>
>> ---------
>> Arnaud
>>
>> Le 14 sept. 2013 à 19:30, Fred Cooke <fr...@gmail.com> a écrit :
>>
>>> You're in Git now. You don't *have* to push your tag and release
>> commits up
>>> to the public world until AFTER you've checked they're OK. Or by
>> failed
>>> release do you mean voted down? They could live on branches until set
>>> in
>>> stone, then merge --ff-only into master at that point, if so.
>>>
>>>
>>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <ja...@tesla.io>
>> wrote:
>>>
>>>> When a release fails like this it is annoying to have to rev back the
>>>> version of the POM. I'm not sure who flipped the versions in the
>> POM and
>>>> while it's a little more visible to see what you're moving
>> toward I prefer
>>>> the pattern of:
>>>>
>>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 -->
>> 3.1-SNAPSHOT
>>>>
>>>> I know this may not be obvious to the casual observer as they may
>>>> think
>>>> 3.1 is next, but I'm personally fine with that.
>>>>
>>>> Especially after a failed release because then I don't have to go
>> change
>>>> all the POMs (whether rolling back manually, using the release
>> rollback,
>>>> the version:set command, or whatever else). It's much easier to
>> just fix
>>>> what's necessary and carry on.
>>>>
>>>> Unless anyone objects I would like to go back this pattern, what I
>>>> previously had, because it's far easier to manage. Ideally it might
>> be nice
>>>> if all the tools understood 3.1.z-SNAPSHOT but they don't an in
>> lieu of
>>>> that I would prefer not to diddle POMs after a failed release.
>>>>
>>>> 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Mark Struberg <st...@yahoo.de>.
In DeltaSpike I always push the release branch + tag to my personal github repo. After the VOTE did succeed I push the exact sha1 upstream to the ASF repo.
This is not perfect but it's good enough imo as the parent commit is verifiable coming from the ASF upstream repo.
Plus people can check that the tag they voted on is exactly the same I push to the ASF repo later.
The only minor downside is that you really need to merge in the pom version upgrade to the upstream master branch which might have changes already.
LieGrue,
strub
----- Original Message -----
> From: Jason van Zyl <ja...@tesla.io>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Saturday, 14 September 2013, 20:47
> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>
> We need a slight modification of this strategy because the changes need to be
> pushed somewhere so that people can examine the tag if they want during the
> release. I can't keep it on my machine until the vote passes.
>
> On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>> +1, that's what we also use in DeltaSpike and dozen other projects.
>> pushChanges=false + localCheckout=true for the win!
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Arnaud Héritier <ah...@gmail.com>
>>> To: Maven Developers List <de...@maven.apache.org>
>>> Cc:
>>> Sent: Saturday, 14 September 2013, 19:45
>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>>
>>> G ood practice too. I'm using it also at work and we are doing our
>>> releases on dedicated branches.
>>>
>>> ---------
>>> Arnaud
>>>
>>> Le 14 sept. 2013 à 19:30, Fred Cooke <fr...@gmail.com> a
> écrit :
>>>
>>>> You're in Git now. You don't *have* to push your tag and
> release
>>> commits up
>>>> to the public world until AFTER you've checked they're OK.
> Or by
>>> failed
>>>> release do you mean voted down? They could live on branches until
> set in
>>>> stone, then merge --ff-only into master at that point, if so.
>>>>
>>>>
>>>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl
> <ja...@tesla.io>
>>> wrote:
>>>>
>>>>> When a release fails like this it is annoying to have to rev
> back the
>>>>> version of the POM. I'm not sure who flipped the versions
> in the
>>> POM and
>>>>> while it's a little more visible to see what you're
> moving
>>> toward I prefer
>>>>> the pattern of:
>>>>>
>>>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2
> -->
>>> 3.1-SNAPSHOT
>>>>>
>>>>> I know this may not be obvious to the casual observer as they
> may think
>>>>> 3.1 is next, but I'm personally fine with that.
>>>>>
>>>>> Especially after a failed release because then I don't have
> to go
>>> change
>>>>> all the POMs (whether rolling back manually, using the release
>>> rollback,
>>>>> the version:set command, or whatever else). It's much
> easier to
>>> just fix
>>>>> what's necessary and carry on.
>>>>>
>>>>> Unless anyone objects I would like to go back this pattern,
> what I
>>>>> previously had, because it's far easier to manage. Ideally
> it might
>>> be nice
>>>>> if all the tools understood 3.1.z-SNAPSHOT but they don't
> an in
>>> lieu of
>>>>> that I would prefer not to diddle POMs after a failed release.
>>>>>
>>>>> 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Mark Struberg <st...@yahoo.de>.
No, a tag and a branch is not only just a label.
GIT internally has a kind of garbage collection. And once some commits are not referenced by another tree they are subject to be dropped from the repo on a re-pack which might happen on git-prune or git-gc. But that's nit picking.
The real problem is that our main repo is always pulled to tons of downstream repos. And they don't forget anything. This is why I suggest the 2nd repo which is a kind of throw-away repo which is not intended for downstream usage.
I fully agree with you that master should be left alone until the VOTE has succeeded.
LieGrue,
strub
>________________________________
> From: Fred Cooke <fr...@gmail.com>
>To: Maven Developers List <de...@maven.apache.org>; Mark Struberg <st...@yahoo.de>
>Sent: Saturday, 14 September 2013, 21:43
>Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>
>
>
>I believe the strict policy only applies to master branch. The entire concept is different anyway, it's just a label. Leave it there, it costs nothing except name space. The persistent try-1 try-2 etc tags will also get mirrored into perpetuity anyway. Master should likely be left alone during a release such that a ff is possible. If changes are required from failed vote, they are made on master, then a new branch is forked off, and try again. If not waiting for that, a full merge would be OK too, there would be no conflict even if the POM had changed in other places. I personally prefer to avoid them where possible, though.
>
>
>
>
>On Sat, Sep 14, 2013 at 9:15 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>The question is not whether you do this on a branch or not, but only where to push this branch to and where people do the validation for the VOTE.
>>
>>GIT repos at the ASF have a strict history-rewrite policy and don't allow to ditch stuff. I'm not 100% sure myself if this is also for deleting upstream branches on the central repo.
>>
>>What might be a solution would be to have a 2nd 'sandbox' GIT repo for each of our 'main' GIT repos for a project. The master of this sandbox GIT repo would automatically get replicated from the main repo and would deny any push to master otherwise. This repo could be used to create temporary playground like feature branches etc. History rewrite and deleting branches and tags would be allowed on this repo. Might be a way to tackle this on ASF hardware without forcing people to use another repo hosting.
>>
>>
>>LieGrue,
>>strub
>>
>>
>>
>>
>>----- Original Message -----
>>
>>> From: Fred Cooke <fr...@gmail.com>
>>> To: Maven Developers List <de...@maven.apache.org>
>>> Cc:
>>
>>> Sent: Saturday, 14 September 2013, 20:48
>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>>
>>> Branches.
>>>
>>>
>>> On Sat, Sep 14, 2013 at 8:47 PM, Jason van Zyl <ja...@tesla.io> wrote:
>>>
>>>> We need a slight modification of this strategy because the changes need to
>>>> be pushed somewhere so that people can examine the tag if they want during
>>>> the release. I can't keep it on my machine until the vote passes.
>>>>
>>>> On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de> wrote:
>>>>
>>>> > +1, that's what we also use in DeltaSpike and dozen other
>>> projects.
>>>> > pushChanges=false + localCheckout=true for the win!
>>>> >
>>>> > LieGrue,
>>>> > strub
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > ----- Original Message -----
>>>> >> From: Arnaud Héritier <ah...@gmail.com>
>>>> >> To: Maven Developers List <de...@maven.apache.org>
>>>> >> Cc:
>>>> >> Sent: Saturday, 14 September 2013, 19:45
>>>> >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>>> >>
>>>> >> G ood practice too. I'm using it also at work and we are doing
>>> our
>>>> >> releases on dedicated branches.
>>>> >>
>>>> >> ---------
>>>> >> Arnaud
>>>> >>
>>>> >> Le 14 sept. 2013 à 19:30, Fred Cooke <fr...@gmail.com>
>>> a écrit :
>>>> >>
>>>> >>> You're in Git now. You don't *have* to push your tag
>>> and release
>>>> >> commits up
>>>> >>> to the public world until AFTER you've checked they're
>>> OK. Or by
>>>> >> failed
>>>> >>> release do you mean voted down? They could live on branches
>>> until set
>>>> in
>>>> >>> stone, then merge --ff-only into master at that point, if so.
>>>> >>>
>>>> >>>
>>>> >>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl
>>> <ja...@tesla.io>
>>>> >> wrote:
>>>> >>>
>>>> >>>> When a release fails like this it is annoying to have to
>>> rev back the
>>>> >>>> version of the POM. I'm not sure who flipped the
>>> versions in the
>>>> >> POM and
>>>> >>>> while it's a little more visible to see what
>>> you're moving
>>>> >> toward I prefer
>>>> >>>> the pattern of:
>>>> >>>>
>>>> >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2
>>> -->
>>>> >> 3.1-SNAPSHOT
>>>> >>>>
>>>> >>>> I know this may not be obvious to the casual observer as
>>> they may
>>>> think
>>>> >>>> 3.1 is next, but I'm personally fine with that.
>>>> >>>>
>>>> >>>> Especially after a failed release because then I don't
>>> have to go
>>>> >> change
>>>> >>>> all the POMs (whether rolling back manually, using the
>>> release
>>>> >> rollback,
>>>> >>>> the version:set command, or whatever else). It's much
>>> easier to
>>>> >> just fix
>>>> >>>> what's necessary and carry on.
>>>> >>>>
>>>> >>>> Unless anyone objects I would like to go back this
>>> pattern, what I
>>>> >>>> previously had, because it's far easier to manage.
>>> Ideally it might
>>>> >> be nice
>>>> >>>> if all the tools understood 3.1.z-SNAPSHOT but they
>>> don't an in
>>>> >> lieu of
>>>> >>>> that I would prefer not to diddle POMs after a failed
>>> release.
>>>> >>>>
>>>> >>>> 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
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
I believe the strict policy only applies to master branch. The entire
concept is different anyway, it's just a label. Leave it there, it costs
nothing except name space. The persistent try-1 try-2 etc tags will also
get mirrored into perpetuity anyway. Master should likely be left alone
during a release such that a ff is possible. If changes are required from
failed vote, they are made on master, then a new branch is forked off, and
try again. If not waiting for that, a full merge would be OK too, there
would be no conflict even if the POM had changed in other places. I
personally prefer to avoid them where possible, though.
On Sat, Sep 14, 2013 at 9:15 PM, Mark Struberg <st...@yahoo.de> wrote:
> The question is not whether you do this on a branch or not, but only where
> to push this branch to and where people do the validation for the VOTE.
>
> GIT repos at the ASF have a strict history-rewrite policy and don't allow
> to ditch stuff. I'm not 100% sure myself if this is also for deleting
> upstream branches on the central repo.
>
> What might be a solution would be to have a 2nd 'sandbox' GIT repo for
> each of our 'main' GIT repos for a project. The master of this sandbox GIT
> repo would automatically get replicated from the main repo and would deny
> any push to master otherwise. This repo could be used to create temporary
> playground like feature branches etc. History rewrite and deleting branches
> and tags would be allowed on this repo. Might be a way to tackle this on
> ASF hardware without forcing people to use another repo hosting.
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: Fred Cooke <fr...@gmail.com>
> > To: Maven Developers List <de...@maven.apache.org>
> > Cc:
> > Sent: Saturday, 14 September 2013, 20:48
> > Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >
> > Branches.
> >
> >
> > On Sat, Sep 14, 2013 at 8:47 PM, Jason van Zyl <ja...@tesla.io> wrote:
> >
> >> We need a slight modification of this strategy because the changes
> need to
> >> be pushed somewhere so that people can examine the tag if they want
> during
> >> the release. I can't keep it on my machine until the vote passes.
> >>
> >> On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de> wrote:
> >>
> >> > +1, that's what we also use in DeltaSpike and dozen other
> > projects.
> >> > pushChanges=false + localCheckout=true for the win!
> >> >
> >> > LieGrue,
> >> > strub
> >> >
> >> >
> >> >
> >> >
> >> > ----- Original Message -----
> >> >> From: Arnaud Héritier <ah...@gmail.com>
> >> >> To: Maven Developers List <de...@maven.apache.org>
> >> >> Cc:
> >> >> Sent: Saturday, 14 September 2013, 19:45
> >> >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >> >>
> >> >> G ood practice too. I'm using it also at work and we are doing
> > our
> >> >> releases on dedicated branches.
> >> >>
> >> >> ---------
> >> >> Arnaud
> >> >>
> >> >> Le 14 sept. 2013 à 19:30, Fred Cooke <fr...@gmail.com>
> > a écrit :
> >> >>
> >> >>> You're in Git now. You don't *have* to push your tag
> > and release
> >> >> commits up
> >> >>> to the public world until AFTER you've checked they're
> > OK. Or by
> >> >> failed
> >> >>> release do you mean voted down? They could live on branches
> > until set
> >> in
> >> >>> stone, then merge --ff-only into master at that point, if so.
> >> >>>
> >> >>>
> >> >>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl
> > <ja...@tesla.io>
> >> >> wrote:
> >> >>>
> >> >>>> When a release fails like this it is annoying to have to
> > rev back the
> >> >>>> version of the POM. I'm not sure who flipped the
> > versions in the
> >> >> POM and
> >> >>>> while it's a little more visible to see what
> > you're moving
> >> >> toward I prefer
> >> >>>> the pattern of:
> >> >>>>
> >> >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2
> > -->
> >> >> 3.1-SNAPSHOT
> >> >>>>
> >> >>>> I know this may not be obvious to the casual observer as
> > they may
> >> think
> >> >>>> 3.1 is next, but I'm personally fine with that.
> >> >>>>
> >> >>>> Especially after a failed release because then I don't
> > have to go
> >> >> change
> >> >>>> all the POMs (whether rolling back manually, using the
> > release
> >> >> rollback,
> >> >>>> the version:set command, or whatever else). It's much
> > easier to
> >> >> just fix
> >> >>>> what's necessary and carry on.
> >> >>>>
> >> >>>> Unless anyone objects I would like to go back this
> > pattern, what I
> >> >>>> previously had, because it's far easier to manage.
> > Ideally it might
> >> >> be nice
> >> >>>> if all the tools understood 3.1.z-SNAPSHOT but they
> > don't an in
> >> >> lieu of
> >> >>>> that I would prefer not to diddle POMs after a failed
> > release.
> >> >>>>
> >> >>>> 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Mark Struberg <st...@yahoo.de>.
The question is not whether you do this on a branch or not, but only where to push this branch to and where people do the validation for the VOTE.
GIT repos at the ASF have a strict history-rewrite policy and don't allow to ditch stuff. I'm not 100% sure myself if this is also for deleting upstream branches on the central repo.
What might be a solution would be to have a 2nd 'sandbox' GIT repo for each of our 'main' GIT repos for a project. The master of this sandbox GIT repo would automatically get replicated from the main repo and would deny any push to master otherwise. This repo could be used to create temporary playground like feature branches etc. History rewrite and deleting branches and tags would be allowed on this repo. Might be a way to tackle this on ASF hardware without forcing people to use another repo hosting.
LieGrue,
strub
----- Original Message -----
> From: Fred Cooke <fr...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Saturday, 14 September 2013, 20:48
> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>
> Branches.
>
>
> On Sat, Sep 14, 2013 at 8:47 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
>> We need a slight modification of this strategy because the changes need to
>> be pushed somewhere so that people can examine the tag if they want during
>> the release. I can't keep it on my machine until the vote passes.
>>
>> On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de> wrote:
>>
>> > +1, that's what we also use in DeltaSpike and dozen other
> projects.
>> > pushChanges=false + localCheckout=true for the win!
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> >
>> > ----- Original Message -----
>> >> From: Arnaud Héritier <ah...@gmail.com>
>> >> To: Maven Developers List <de...@maven.apache.org>
>> >> Cc:
>> >> Sent: Saturday, 14 September 2013, 19:45
>> >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>> >>
>> >> G ood practice too. I'm using it also at work and we are doing
> our
>> >> releases on dedicated branches.
>> >>
>> >> ---------
>> >> Arnaud
>> >>
>> >> Le 14 sept. 2013 à 19:30, Fred Cooke <fr...@gmail.com>
> a écrit :
>> >>
>> >>> You're in Git now. You don't *have* to push your tag
> and release
>> >> commits up
>> >>> to the public world until AFTER you've checked they're
> OK. Or by
>> >> failed
>> >>> release do you mean voted down? They could live on branches
> until set
>> in
>> >>> stone, then merge --ff-only into master at that point, if so.
>> >>>
>> >>>
>> >>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl
> <ja...@tesla.io>
>> >> wrote:
>> >>>
>> >>>> When a release fails like this it is annoying to have to
> rev back the
>> >>>> version of the POM. I'm not sure who flipped the
> versions in the
>> >> POM and
>> >>>> while it's a little more visible to see what
> you're moving
>> >> toward I prefer
>> >>>> the pattern of:
>> >>>>
>> >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2
> -->
>> >> 3.1-SNAPSHOT
>> >>>>
>> >>>> I know this may not be obvious to the casual observer as
> they may
>> think
>> >>>> 3.1 is next, but I'm personally fine with that.
>> >>>>
>> >>>> Especially after a failed release because then I don't
> have to go
>> >> change
>> >>>> all the POMs (whether rolling back manually, using the
> release
>> >> rollback,
>> >>>> the version:set command, or whatever else). It's much
> easier to
>> >> just fix
>> >>>> what's necessary and carry on.
>> >>>>
>> >>>> Unless anyone objects I would like to go back this
> pattern, what I
>> >>>> previously had, because it's far easier to manage.
> Ideally it might
>> >> be nice
>> >>>> if all the tools understood 3.1.z-SNAPSHOT but they
> don't an in
>> >> lieu of
>> >>>> that I would prefer not to diddle POMs after a failed
> release.
>> >>>>
>> >>>> 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
Branches.
On Sat, Sep 14, 2013 at 8:47 PM, Jason van Zyl <ja...@tesla.io> wrote:
> We need a slight modification of this strategy because the changes need to
> be pushed somewhere so that people can examine the tag if they want during
> the release. I can't keep it on my machine until the vote passes.
>
> On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de> wrote:
>
> > +1, that's what we also use in DeltaSpike and dozen other projects.
> > pushChanges=false + localCheckout=true for the win!
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > ----- Original Message -----
> >> From: Arnaud Héritier <ah...@gmail.com>
> >> To: Maven Developers List <de...@maven.apache.org>
> >> Cc:
> >> Sent: Saturday, 14 September 2013, 19:45
> >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >>
> >> G ood practice too. I'm using it also at work and we are doing our
> >> releases on dedicated branches.
> >>
> >> ---------
> >> Arnaud
> >>
> >> Le 14 sept. 2013 à 19:30, Fred Cooke <fr...@gmail.com> a écrit :
> >>
> >>> You're in Git now. You don't *have* to push your tag and release
> >> commits up
> >>> to the public world until AFTER you've checked they're OK. Or by
> >> failed
> >>> release do you mean voted down? They could live on branches until set
> in
> >>> stone, then merge --ff-only into master at that point, if so.
> >>>
> >>>
> >>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <ja...@tesla.io>
> >> wrote:
> >>>
> >>>> When a release fails like this it is annoying to have to rev back the
> >>>> version of the POM. I'm not sure who flipped the versions in the
> >> POM and
> >>>> while it's a little more visible to see what you're moving
> >> toward I prefer
> >>>> the pattern of:
> >>>>
> >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 -->
> >> 3.1-SNAPSHOT
> >>>>
> >>>> I know this may not be obvious to the casual observer as they may
> think
> >>>> 3.1 is next, but I'm personally fine with that.
> >>>>
> >>>> Especially after a failed release because then I don't have to go
> >> change
> >>>> all the POMs (whether rolling back manually, using the release
> >> rollback,
> >>>> the version:set command, or whatever else). It's much easier to
> >> just fix
> >>>> what's necessary and carry on.
> >>>>
> >>>> Unless anyone objects I would like to go back this pattern, what I
> >>>> previously had, because it's far easier to manage. Ideally it might
> >> be nice
> >>>> if all the tools understood 3.1.z-SNAPSHOT but they don't an in
> >> lieu of
> >>>> that I would prefer not to diddle POMs after a failed release.
> >>>>
> >>>> 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
> ---------------------------------------------------------
>
>
>
>
>
>
>
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Mirko Friedenhagen <mf...@gmail.com>.
Json,
the JDK7 just went from 25 to 40 for me and I do not mind :-)
Regards Mirko
--
Sent from my mobile
On Sep 15, 2013 2:00 AM, "Jason van Zyl" <ja...@tesla.io> wrote:
> The users may well be developers, but I don't think that warrants changing
> a normal pattern. Maybe only I consider this a normal pattern, but I don't
> know of any examples, personally, where externally represented versions
> have gaps in them. I'd ask you the same question I asked Stephen as to
> whether you know of any projects, or products, that do this? Just because
> we can skip versions isn't a good reason to do so. If lots of projects do
> it then it's worth considering. Have any examples on hand?
>
> For now while I'm doing the core releases, I would prefer not to have
> gaps. Call me provincial, but I'd like to do what we've always done since
> the inception of the project unless there is a compelling reason to do
> otherwise.
>
> On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
>
> > Jason, PLEASE understand that you do NOT have a single user. Not even
> one.
> > Nada. Zilch. You have developers. Developers, by definition, are not
> > *completely* stupid (though some try to fool us!). They can handle
> missing
> > versions. If you released firefox 12 after firefox 10 it would be
> confusing
> > for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
> > moron would be confused by this. Few developers are that stupid, and
> those
> > who are have limited months of career as a dev ahead of them. "it's
> > confusing" holds no water in the context of a hard-core dev tool IMO.
> >
> >
> > On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> >> The difference is that you say those versions did not pass QA.
> >>
> >> As a user I'd rather know that what I have *unabiguously* passed QA
> >> (whatever that QA process is, and however lax it is) than know the
> >> increasing version numbers. On top of that, if we go increasing, with no
> >> skips, we are actually giving people a false sense of extra QA... By
> >> telling people "go to this page where we list the status of each
> version"
> >> then they will not be confused at all... Instead they get greater
> >> confidence...
> >>
> >> They will see
> >>
> >> * some versions we never released a binary for... Those were really bad
> >>
> >> * some versions we released a binary for... And then found critical
> bugs is
> >>
> >> * some versions we released a binary for, but its only recent so there
> >> could be regressions our test suite missed
> >>
> >> * some versions we reased a binary for, have had no serious issues
> raised
> >> for the past 6 weeks and are considered stable
> >>
> >> * some versions we no longer recommend
> >>
> >> As a user such a page gives me much more confidence in the project
> rather
> >> than our current "every release is a release" lase fair attitude that
> saw
> >> 2.1.0 pushed as the latest for longer than was healthy given the
> artifact
> >> signing issues. As a user it also gives me more confidence that once I
> see
> >> a new release transition to stable (say 6 weeks) or recommended (say 3
> >> months) that I am following the project guidelines
> >>
> >> I am not saying the version would be missing (the tag would always be
> >> there) but that a binary or source dist would not...
> >>
> >> Everyone is entitled to their opinion... previously it was Maven
> developers
> >> who said no missing version... Iirc you are the first to suggest users
> >> would be confused.... Have we actually asked users which is more
> confusing?
> >>
> >> On Saturday, 14 September 2013, Jason van Zyl wrote:
> >>
> >>> I don't agree. I think this would be massively confusing to people if a
> >>> version was missing, or several failed and you went from 3.1.0 to
> 3.1.3.
> >> I
> >>> don't think that would make much sense to most users.
> >>>
> >>> On Sep 14, 2013, at 5:49 PM, Stephen Connolly <
> >>> stephen.alan.connolly@gmail.com> wrote:
> >>>
> >>>> On Saturday, 14 September 2013, Dennis Lundberg wrote:
> >>>>
> >>>>> JIRA is not a big problem. Say for example that the 3.1.1 release was
> >>>>> abandoned due to some problem, you would simply rename the version in
> >>>>> JIRA from 3.1.1 to 3.1.2.
> >>>>
> >>>>
> >>>> Exactly.
> >>>>
> >>>> Not a problem if you ask me... The only one I can think of if the
> >> javadoc
> >>>> @since tags and even without skipping versions they can end up at a
> >>>> unreleased version label, plus they are just a >= which will be valid
> >>> anyway
> >>>>
> >>>>
> >>>>>
> >>>>> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de>
> >>> wrote:
> >>>>>> I think it's mainly because the maintenance and housekeeping costs
> on
> >>>>> the JIRA front and others which use the version nr as reference.
> >>>>>>
> >>>>>>
> >>>>>> Imagine that you would need to move all the JIRA tickets which got
> >>>>> marked as fixed in a certain release as well. Otherwise the release
> >>> notes
> >>>>> would be broken - or would need to get maintained manually.
> >>>>>>
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: Fred Cooke <fr...@gmail.com>
> >>>>>>> To: Maven Developers List <de...@maven.apache.org>
> >>>>>>> Cc:
> >>>>>>> Sent: Saturday, 14 September 2013, 21:51
> >>>>>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >>>>>>>
> >>>>>>> I agree on skipping failed versions! I was avoiding the topic
> >> because
> >>> it
> >>>>>>> seemed popular opinion was to re-spin endlessly like a child's
> >>> spinning
> >>>>> top.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
> >>>>>>> stephen.alan.connolly@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> Why as long as you don't push the tag, there's no big deal.
> Pushing
> >>>>>>> the tag
> >>>>>>>> is when problems appear... In any case I'd prefer to just skip
> >> failed
> >>>>>>>> version numbers... Though I was voted down last time that came up,
> >>> and
> >>>>>>>> given I'm not running too many releases at the moment, I don't see
> >>>>>>> my
> >>>>>>>> opinion as being heavyweight on that subject... Version numbers
> are
> >>>>> cheap
> >>>>>>>> and we've had borked releases before (eg critical IMHO bugs in
> >> 2.1.0,
> >>>>>>> 2.2.0
> >>>>>>>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
> >>>>>>> that was
> >>>>>>>> not released" argument.
> >>>>>>>>
> >>>>>>>> In my opinion we need a release status page anyway, eg stating
> >>> whether
> >>>>>>>> specific versions are considered stabilising, stable, retired or
> >>>>> advised
> >>>>>>>> not to be used... Such a page would remove the need for recycling
> >>>>> version
> >>>>>>>> numbers *and* provide benefit to users at the same time.
> >>>>>>>>
> >>>>>>>> But I will leave it for others to fight the relative costs of
> >> version
> >>>>>>>> numbers (given the infinite supply) against making sure JIRA
> >> release
> >>>>> notes
> >>>>>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
> >>>>> should be
> >>>>>>>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
> >>>>>>>> required) are correct and saving the risk that a user checks out
> an
> >>>>>>>> unreleased tag and tries to build that from source and then starts
> >>>>> trying
> >>>>>>>> to raise bugs against a non-exist any version!
> >>>>>>>>
> >>>>>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
> >>>>>>>>
> >>>>>>>>> We need a slight modification of this strategy because the
> changes
> >>>>>>> need
> >>>>>>>> to
> >>>>>>>>> be pushed somewhere so that people can examine the tag if they
> >> want
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> <javascript:;><javascript:;>
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> <javascript:;><javascript:;>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Sent from my phone
> >>>
> >>> Thanks,
> >>>
> >>> Jason
> >>>
> >>> ----------------------------------------------------------
> >>> Jason van Zyl
> >>> Founder, Apache Maven
> >>> http://twitter.com/jvanzyl
> >>> ---------------------------------------------------------
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> Sent from my phone
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>
>
>
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
Your poll is a special case, which was separated in the discussions. For
all cases, but especially your special case, a good solution is to do what
some other ASF project does, and vote on SCM, then release once. They build
snapshots (gasp, maven concept in use, and IIRC they don't even use maven),
deploy them somewhere temporary, review, discuss, vote, then either fix and
respin temp stuff, or release proper. This makes a HUGE amount of sense and
is what the gods of Maven have taught me since I was a little boy.
Generally good practice too. Plus, yeah, I'd argue that they are indeed
morons :-p "Maven 4 has been released get it here <url to 4.0.3>" (4.1.3 is
totally absurd...) should confuse no one except morons.
What has LTS got to do with this? Irrelevant as far as I can tell.
Deleting tags is always bad, but in Git it's downright stupid.
Fred.
On Sun, Sep 15, 2013 at 1:18 PM, Robert Scholte <rf...@apache.org>wrote:
> That someone might have been me.
> I did an internal poll to ask if people would understand if Maven would
> jump from 3.0.5 to 4.1.3.
> None of them did, they all wondered what happened to the missing versions.
> Sure they understand that 4.1.3 is newer than 3.0.5, these aren't morons.
>
> One major difference is that Maven can't update itself to the latest
> version. If that would be the case, then versions are only interesting to
> reproduce issues and people often wouldn't see/matter the version.
>
> *If* we would allow gaps, we should also introduce LTS releases.
>
> For now, I'd prefer reusing versions and no gaps. I don't mind deleting
> tags, otherwise I'd prefer the usage of RCx during votes.
>
> Robert
>
> Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke <
> fred.cooke@gmail.com>:
>
>
> Last time someone asked this I went straight to central and found two
>> examples. There are plenty out there. I'm not doing it again, you're more
>> than capable. Also note, it's not much different to go from 3.1.2 to 3.1.4
>> than it is from 3.1.5 to 3.2.0; you still miss out versions, an infinite
>> number of them, in fact.
>>
>> Preferring not to have gaps is a choice and one I was aware you lot would
>> make. That's why I didn't bring it up in the first place despite
>> preferring
>> to just straight miss them. Or just straight publish all releases (as is
>> normal mvn practice since forever) and direct users to the ones that
>> work... I *think* this is what Stephen is trying to say, but if I'm honest
>> I missed out a lot of what he wrote. Forgive me, it's 2am here.
>>
>>
>> On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl <ja...@tesla.io> wrote:
>>
>> The users may well be developers, but I don't think that warrants
>>> changing
>>> a normal pattern. Maybe only I consider this a normal pattern, but I
>>> don't
>>> know of any examples, personally, where externally represented versions
>>> have gaps in them. I'd ask you the same question I asked Stephen as to
>>> whether you know of any projects, or products, that do this? Just because
>>> we can skip versions isn't a good reason to do so. If lots of projects do
>>> it then it's worth considering. Have any examples on hand?
>>>
>>> For now while I'm doing the core releases, I would prefer not to have
>>> gaps. Call me provincial, but I'd like to do what we've always done since
>>> the inception of the project unless there is a compelling reason to do
>>> otherwise.
>>>
>>> On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
>>>
>>> > Jason, PLEASE understand that you do NOT have a single user. Not even
>>> one.
>>> > Nada. Zilch. You have developers. Developers, by definition, are not
>>> > *completely* stupid (though some try to fool us!). They can handle
>>> missing
>>> > versions. If you released firefox 12 after firefox 10 it would be
>>> confusing
>>> > for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
>>> > moron would be confused by this. Few developers are that stupid, and
>>> those
>>> > who are have limited months of career as a dev ahead of them. "it's
>>> > confusing" holds no water in the context of a hard-core dev tool IMO.
>>> >
>>> >
>>> > On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
>>> > stephen.alan.connolly@gmail.**com <st...@gmail.com>>
>>> wrote:
>>> >
>>> >> The difference is that you say those versions did not pass QA.
>>> >>
>>> >> As a user I'd rather know that what I have *unabiguously* passed QA
>>> >> (whatever that QA process is, and however lax it is) than know the
>>> >> increasing version numbers. On top of that, if we go increasing, with
>>> no
>>> >> skips, we are actually giving people a false sense of extra QA... By
>>> >> telling people "go to this page where we list the status of each
>>> version"
>>> >> then they will not be confused at all... Instead they get greater
>>> >> confidence...
>>> >>
>>> >> They will see
>>> >>
>>> >> * some versions we never released a binary for... Those were really
>>> bad
>>> >>
>>> >> * some versions we released a binary for... And then found critical
>>> bugs is
>>> >>
>>> >> * some versions we released a binary for, but its only recent so there
>>> >> could be regressions our test suite missed
>>> >>
>>> >> * some versions we reased a binary for, have had no serious issues
>>> raised
>>> >> for the past 6 weeks and are considered stable
>>> >>
>>> >> * some versions we no longer recommend
>>> >>
>>> >> As a user such a page gives me much more confidence in the project
>>> rather
>>> >> than our current "every release is a release" lase fair attitude that
>>> saw
>>> >> 2.1.0 pushed as the latest for longer than was healthy given the
>>> artifact
>>> >> signing issues. As a user it also gives me more confidence that once I
>>> see
>>> >> a new release transition to stable (say 6 weeks) or recommended (say 3
>>> >> months) that I am following the project guidelines
>>> >>
>>> >> I am not saying the version would be missing (the tag would always be
>>> >> there) but that a binary or source dist would not...
>>> >>
>>> >> Everyone is entitled to their opinion... previously it was Maven
>>> developers
>>> >> who said no missing version... Iirc you are the first to suggest users
>>> >> would be confused.... Have we actually asked users which is more
>>> confusing?
>>> >>
>>> >> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>> >>
>>> >>> I don't agree. I think this would be massively confusing to people
>>> if a
>>> >>> version was missing, or several failed and you went from 3.1.0 to
>>> 3.1.3.
>>> >> I
>>> >>> don't think that would make much sense to most users.
>>> >>>
>>> >>> On Sep 14, 2013, at 5:49 PM, Stephen Connolly <
>>> >>> stephen.alan.connolly@gmail.**com <st...@gmail.com>>
>>> wrote:
>>> >>>
>>> >>>> On Saturday, 14 September 2013, Dennis Lundberg wrote:
>>> >>>>
>>> >>>>> JIRA is not a big problem. Say for example that the 3.1.1 release
>>> was
>>> >>>>> abandoned due to some problem, you would simply rename the version
>>> in
>>> >>>>> JIRA from 3.1.1 to 3.1.2.
>>> >>>>
>>> >>>>
>>> >>>> Exactly.
>>> >>>>
>>> >>>> Not a problem if you ask me... The only one I can think of if the
>>> >> javadoc
>>> >>>> @since tags and even without skipping versions they can end up at a
>>> >>>> unreleased version label, plus they are just a >= which will be
>>> valid
>>> >>> anyway
>>> >>>>
>>> >>>>
>>> >>>>>
>>> >>>>> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <struberg@yahoo.de
>>> >
>>> >>> wrote:
>>> >>>>>> I think it's mainly because the maintenance and housekeeping costs
>>> on
>>> >>>>> the JIRA front and others which use the version nr as reference.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Imagine that you would need to move all the JIRA tickets which got
>>> >>>>> marked as fixed in a certain release as well. Otherwise the release
>>> >>> notes
>>> >>>>> would be broken - or would need to get maintained manually.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> LieGrue,
>>> >>>>>> strub
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> ----- Original Message -----
>>> >>>>>>> From: Fred Cooke <fr...@gmail.com>
>>> >>>>>>> To: Maven Developers List <de...@maven.apache.org>
>>> >>>>>>> Cc:
>>> >>>>>>> Sent: Saturday, 14 September 2013, 21:51
>>> >>>>>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>> >>>>>>>
>>> >>>>>>> I agree on skipping failed versions! I was avoiding the topic
>>> >> because
>>> >>> it
>>> >>>>>>> seemed popular opinion was to re-spin endlessly like a child's
>>> >>> spinning
>>> >>>>> top.
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
>>> >>>>>>> stephen.alan.connolly@gmail.**com<st...@gmail.com>>
>>> wrote:
>>> >>>>>>>
>>> >>>>>>>> Why as long as you don't push the tag, there's no big deal.
>>> Pushing
>>> >>>>>>> the tag
>>> >>>>>>>> is when problems appear... In any case I'd prefer to just skip
>>> >> failed
>>> >>>>>>>> version numbers... Though I was voted down last time that came
>>> up,
>>> >>> and
>>> >>>>>>>> given I'm not running too many releases at the moment, I don't
>>> see
>>> >>>>>>> my
>>> >>>>>>>> opinion as being heavyweight on that subject... Version numbers
>>> are
>>> >>>>> cheap
>>> >>>>>>>> and we've had borked releases before (eg critical IMHO bugs in
>>> >> 2.1.0,
>>> >>>>>>> 2.2.0
>>> >>>>>>>> and 3.1.0...) so I don't buy the "what if a user checks out a
>>> tag
>>> >>>>>>> that was
>>> >>>>>>>> not released" argument.
>>> >>>>>>>>
>>> >>>>>>>> In my opinion we need a release status page anyway, eg stating
>>> >>> whether
>>> >>>>>>>> specific versions are considered stabilising, stable, retired or
>>> >>>>> advised
>>> >>>>>>>> not to be used... Such a page would remove the need for
>>> recycling
>>> >>>>> version
>>> >>>>>>>> numbers *and* provide benefit to users at the same time.
>>> >>>>>>>>
>>> >>>>>>>> But I will leave it for others to fight the relative costs of
>>> >> version
>>> >>>>>>>> numbers (given the infinite supply) against making sure JIRA
>>> >> release
>>> >>>>> notes
>>> >>>>>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
>>> >>>>> should be
>>> >>>>>>>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
>>> >>>>>>>> required) are correct and saving the risk that a user checks out
>>> an
>>> >>>>>>>> unreleased tag and tries to build that from source and then
>>> starts
>>> >>>>> trying
>>> >>>>>>>> to raise bugs against a non-exist any version!
>>> >>>>>>>>
>>> >>>>>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>> >>>>>>>>
>>> >>>>>>>>> We need a slight modification of this strategy because the
>>> changes
>>> >>>>>>> need
>>> >>>>>>>> to
>>> >>>>>>>>> be pushed somewhere so that people can examine the tag if they
>>> >> want
>>> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>>> >> <javascript:;><javascript:;>
>>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> >> <javascript:;><javascript:;>
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>> --
>>> >>>> Sent from my phone
>>> >>>
>>> >>> Thanks,
>>> >>>
>>> >>> Jason
>>> >>>
>>> >>> ------------------------------**----------------------------
>>> >>> Jason van Zyl
>>> >>> Founder, Apache Maven
>>> >>> http://twitter.com/jvanzyl
>>> >>> ------------------------------**---------------------------
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >> --
>>> >> Sent from my phone
>>> >>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ------------------------------**----------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ------------------------------**---------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
That's why I said to use branches. Braches XOR skip versions. I prefer the
latter, though they can be mixed too.
On Mon, Sep 16, 2013 at 1:22 AM, sebb <se...@gmail.com> wrote:
> Some other ASF PMCs have no qualms about skipping version numbers.
>
> For example AIUI Tomcat creates a release candidate, and if the vote
> fails, they bump the patch version.
> For example they released 7.0.30 and 7.0.32; there is no 7.0.31.
>
> The other point I would make is that bumping the way the release
> plugin currently works has some problems.
> It should not update trunk until the release succeeds.
> There would then be no need to fix up trunk if a release vote fails.
> See MRELEASE-721
>
>
> On 15 September 2013 13:49, Stephen Connolly
> <st...@gmail.com> wrote:
> > Another data point is exactly how many times have we got patch release
> .0 right?
> >
> > 2.1.0 - seriously borked use 2.2.1
> > 2.2.0 - seriously borked use 2.2.1
> > 3.0.0-3.0.2 - not recommended for use
> > 3.0.3 - ok but has issues with release plugin
> > 3.0.4 - first 3.x that could be considered stable
> > 3.1.0 - borked enough to recommend not for production IMHO
> >
> > From experience I, as a PMC member, do not recommend my day job picking
> up a x.y.0 from Maven... So why should we hold patch numbers as special
> enough that they must increase by 1 between "blessed" releases *when we
> cannot even guarantee that a "blessed" release is ready for production?*
> >
> > Maybe we should split this into another DISCUSS thread, though I am
> conscious that this subject is distracting from actually getting releases
> out the door... OTOH allowing skips in patch release numbers would allow
> work on core to continue without having to coordinate a "nobody commit to
> master while vote in play" policy which seems completely against how one
> should use GIT
> >
> > Sent from my iPhone
> >
> > On 15 Sep 2013, at 12:30, Fred Cooke <fr...@gmail.com> wrote:
> >
> >> Exactly! :-)
> >>
> >>
> >> On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly <
> >> stephen.alan.connolly@gmail.com> wrote:
> >>
> >>> But you asked the wrong jump then.
> >>>
> >>> It would be 3.0.5 to 4.0.4... There's no way we'd skip 4.0.x to go to
> 4.1.x
> >>> if we have not had a 4.0.x released at all.
> >>>
> >>> My point is patch version people are perfectly fine with skips....
> Minor
> >>> version skips would be bad, but there is zero need for them.
> >>>
> >>> On Sunday, 15 September 2013, Robert Scholte wrote:
> >>>
> >>>> That someone might have been me.
> >>>> I did an internal poll to ask if people would understand if Maven
> would
> >>>> jump from 3.0.5 to 4.1.3.
> >>>> None of them did, they all wondered what happened to the missing
> >>> versions.
> >>>> Sure they understand that 4.1.3 is newer than 3.0.5, these aren't
> morons.
> >>>>
> >>>> One major difference is that Maven can't update itself to the latest
> >>>> version. If that would be the case, then versions are only
> interesting to
> >>>> reproduce issues and people often wouldn't see/matter the version.
> >>>>
> >>>> *If* we would allow gaps, we should also introduce LTS releases.
> >>>>
> >>>> For now, I'd prefer reusing versions and no gaps. I don't mind
> deleting
> >>>> tags, otherwise I'd prefer the usage of RCx during votes.
> >>>>
> >>>> Robert
> >>>>
> >>>> Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke <
> >>>> fred.cooke@gmail.com>:
> >>>>
> >>>> Last time someone asked this I went straight to central and found two
> >>>> examples. There are plenty out there. I'm not doing it again, you're
> more
> >>>> than capable. Also note, it's not much different to go from 3.1.2 to
> >>> 3.1.4
> >>>> than it is from 3.1.5 to 3.2.0; you still miss out versions, an
> infinite
> >>>> number of them, in fact.
> >>>>
> >>>> Preferring not to have gaps is a choice and one I was aware you lot
> would
> >>>> make. That's why I didn't bring it up in the first place despite
> >>> preferring
> >>>> to just straight miss them. Or just straight publish all releases (as
> is
> >>>> normal mvn practice since forever) and direct users to the ones that
> >>>> work... I *think* this is what Stephen is trying to say, but if I'm
> >>> honest
> >>>> I missed out a lot of what he wrote. Forgive me, it's 2am here.
> >>>>
> >>>>
> >>>> On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl <ja...@tesla.io>
> wrote:
> >>>>
> >>>> The users may well be developers, but I don't think that warrants
> >>> changing
> >>>> a normal pattern. Maybe only I consider this a normal pattern, but I
> >>> don't
> >>>> know of any examples, personally, where externally represented
> versions
> >>>> have gaps in them. I'd ask you the same question I asked Stephen as to
> >>>> whether you know of any projects, or products, that do this? Just
> because
> >>>> we can skip versions isn't a good reason to do so. If lots of
> projects do
> >>>> it then it's worth considering. Have any examples on hand?
> >>>>
> >>>> For now while I'm doing the core releases, I would prefer not to have
> >>>> gaps. Call me provincial, but I'd like to do what we've always done
> since
> >>>> the inception of the project unless there is a compelling reason to do
> >>>> otherwise.
> >>>>
> >>>> On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
> >>>>
> >>>>> Jason, PLEASE understand that you do NOT have a single user. Not even
> >>>> one.
> >>>>> Nada. Zilch. You have developers. Developers, by definition, are not
> >>>>> *completely* stupid (though some try to fool us!). They can handle
> >>>> missing
> >>>>> versions. If you released firefox 12 after firefox 10 it would be
> >>>> confusing
> >>>>> for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and
> utter
> >>>>> moron would be confused by this. Few developers are that stupid, and
> >>>> those
> >>>>> who are have limited months of career as a dev ahead of them. "it's
> >>>>> confusing" holds no water in the context of a hard-core dev tool IMO.
> >>>>>
> >>>>>
> >>>>> On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
> >>>>> stephen.alan.connolly@gmail.com> wrote:
> >>>>>
> >>>>>> The difference is that you say those versions did not pass QA.
> >>>>>>
> >>>>>> As a user I'd rather know that what I have *unabiguously* passed QA
> >>>>>> (whatever that QA process is, and however lax it is) than know the
> >>>>>> increasing version numbers. On top of that, if we go increasing,
> with
> >>> no
> >>>>>> skips, we are actually giving people a false sense of extra QA... By
> >>>>>> telling people "go to this page where we list the status of each
> >>>> version"
> >>>>>> then they will not be confused at all... Instead they get greater
> >>>>>> confidence...
> >>>>>>
> >>>>>> They will see
> >>>>>>
> >>>>>> * some versions we never released a binary for... Those were really
> >>> bad
> >>>>>>
> >>>>>> * some versions we released a binary for... And then found critical
> >>>> bugs is
> >>>>>>
> >>>>>> * some versions we released a binary for, but its only recent so
> there
> >>>>>> could be regressions our test suite missed
> >>>>>>
> >>>>>> * some versions we reased a binary for, have had no serious issues
> >>>> raised
> >>>>>> for the past 6 weeks and are considered stable
> >>>>>>
> >>>>>> * some versions we no longer recommend
> >>>>>>
> >>>>>> As a user such a page gives me much more confidence in the project
> >>>> rather
> >>>>>> than our current "every release is a release" lase fair attitude
> that
> >>>> saw
> >>>>>> 2.1.0 pushed as the latest for longer than was healthy given the
> >>>> artifact
> >>>>>> signing issues. As a user it also gives me more confidence that
> once I
> >>>> see
> >>>>>> a new release transition to stable (say 6 weeks) or recommended
> (say 3
> >>>>>> months) that I am following the project guidelines
> >>>>>>
> >>>>>> I am not saying the version would be missing (the tag would always
> be
> >>>>>> there) but that a binary or source dist would not...
> >>>>>>
> >>>>>> Everyone is entitled to their opinion... previously it was Maven
> >>>> developers
> >>>>>> who said no missing version... Iirc you are the first to suggest
> users
> >>>>>> would be confused.... Have we actually asked users which is more
> >>>> confusing?
> >>>>
> >>>>
> ------------------------------**------------------------------**---------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>> --
> >>> Sent from my phone
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by sebb <se...@gmail.com>.
Some other ASF PMCs have no qualms about skipping version numbers.
For example AIUI Tomcat creates a release candidate, and if the vote
fails, they bump the patch version.
For example they released 7.0.30 and 7.0.32; there is no 7.0.31.
The other point I would make is that bumping the way the release
plugin currently works has some problems.
It should not update trunk until the release succeeds.
There would then be no need to fix up trunk if a release vote fails.
See MRELEASE-721
On 15 September 2013 13:49, Stephen Connolly
<st...@gmail.com> wrote:
> Another data point is exactly how many times have we got patch release .0 right?
>
> 2.1.0 - seriously borked use 2.2.1
> 2.2.0 - seriously borked use 2.2.1
> 3.0.0-3.0.2 - not recommended for use
> 3.0.3 - ok but has issues with release plugin
> 3.0.4 - first 3.x that could be considered stable
> 3.1.0 - borked enough to recommend not for production IMHO
>
> From experience I, as a PMC member, do not recommend my day job picking up a x.y.0 from Maven... So why should we hold patch numbers as special enough that they must increase by 1 between "blessed" releases *when we cannot even guarantee that a "blessed" release is ready for production?*
>
> Maybe we should split this into another DISCUSS thread, though I am conscious that this subject is distracting from actually getting releases out the door... OTOH allowing skips in patch release numbers would allow work on core to continue without having to coordinate a "nobody commit to master while vote in play" policy which seems completely against how one should use GIT
>
> Sent from my iPhone
>
> On 15 Sep 2013, at 12:30, Fred Cooke <fr...@gmail.com> wrote:
>
>> Exactly! :-)
>>
>>
>> On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> But you asked the wrong jump then.
>>>
>>> It would be 3.0.5 to 4.0.4... There's no way we'd skip 4.0.x to go to 4.1.x
>>> if we have not had a 4.0.x released at all.
>>>
>>> My point is patch version people are perfectly fine with skips.... Minor
>>> version skips would be bad, but there is zero need for them.
>>>
>>> On Sunday, 15 September 2013, Robert Scholte wrote:
>>>
>>>> That someone might have been me.
>>>> I did an internal poll to ask if people would understand if Maven would
>>>> jump from 3.0.5 to 4.1.3.
>>>> None of them did, they all wondered what happened to the missing
>>> versions.
>>>> Sure they understand that 4.1.3 is newer than 3.0.5, these aren't morons.
>>>>
>>>> One major difference is that Maven can't update itself to the latest
>>>> version. If that would be the case, then versions are only interesting to
>>>> reproduce issues and people often wouldn't see/matter the version.
>>>>
>>>> *If* we would allow gaps, we should also introduce LTS releases.
>>>>
>>>> For now, I'd prefer reusing versions and no gaps. I don't mind deleting
>>>> tags, otherwise I'd prefer the usage of RCx during votes.
>>>>
>>>> Robert
>>>>
>>>> Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke <
>>>> fred.cooke@gmail.com>:
>>>>
>>>> Last time someone asked this I went straight to central and found two
>>>> examples. There are plenty out there. I'm not doing it again, you're more
>>>> than capable. Also note, it's not much different to go from 3.1.2 to
>>> 3.1.4
>>>> than it is from 3.1.5 to 3.2.0; you still miss out versions, an infinite
>>>> number of them, in fact.
>>>>
>>>> Preferring not to have gaps is a choice and one I was aware you lot would
>>>> make. That's why I didn't bring it up in the first place despite
>>> preferring
>>>> to just straight miss them. Or just straight publish all releases (as is
>>>> normal mvn practice since forever) and direct users to the ones that
>>>> work... I *think* this is what Stephen is trying to say, but if I'm
>>> honest
>>>> I missed out a lot of what he wrote. Forgive me, it's 2am here.
>>>>
>>>>
>>>> On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl <ja...@tesla.io> wrote:
>>>>
>>>> The users may well be developers, but I don't think that warrants
>>> changing
>>>> a normal pattern. Maybe only I consider this a normal pattern, but I
>>> don't
>>>> know of any examples, personally, where externally represented versions
>>>> have gaps in them. I'd ask you the same question I asked Stephen as to
>>>> whether you know of any projects, or products, that do this? Just because
>>>> we can skip versions isn't a good reason to do so. If lots of projects do
>>>> it then it's worth considering. Have any examples on hand?
>>>>
>>>> For now while I'm doing the core releases, I would prefer not to have
>>>> gaps. Call me provincial, but I'd like to do what we've always done since
>>>> the inception of the project unless there is a compelling reason to do
>>>> otherwise.
>>>>
>>>> On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
>>>>
>>>>> Jason, PLEASE understand that you do NOT have a single user. Not even
>>>> one.
>>>>> Nada. Zilch. You have developers. Developers, by definition, are not
>>>>> *completely* stupid (though some try to fool us!). They can handle
>>>> missing
>>>>> versions. If you released firefox 12 after firefox 10 it would be
>>>> confusing
>>>>> for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
>>>>> moron would be confused by this. Few developers are that stupid, and
>>>> those
>>>>> who are have limited months of career as a dev ahead of them. "it's
>>>>> confusing" holds no water in the context of a hard-core dev tool IMO.
>>>>>
>>>>>
>>>>> On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>
>>>>>> The difference is that you say those versions did not pass QA.
>>>>>>
>>>>>> As a user I'd rather know that what I have *unabiguously* passed QA
>>>>>> (whatever that QA process is, and however lax it is) than know the
>>>>>> increasing version numbers. On top of that, if we go increasing, with
>>> no
>>>>>> skips, we are actually giving people a false sense of extra QA... By
>>>>>> telling people "go to this page where we list the status of each
>>>> version"
>>>>>> then they will not be confused at all... Instead they get greater
>>>>>> confidence...
>>>>>>
>>>>>> They will see
>>>>>>
>>>>>> * some versions we never released a binary for... Those were really
>>> bad
>>>>>>
>>>>>> * some versions we released a binary for... And then found critical
>>>> bugs is
>>>>>>
>>>>>> * some versions we released a binary for, but its only recent so there
>>>>>> could be regressions our test suite missed
>>>>>>
>>>>>> * some versions we reased a binary for, have had no serious issues
>>>> raised
>>>>>> for the past 6 weeks and are considered stable
>>>>>>
>>>>>> * some versions we no longer recommend
>>>>>>
>>>>>> As a user such a page gives me much more confidence in the project
>>>> rather
>>>>>> than our current "every release is a release" lase fair attitude that
>>>> saw
>>>>>> 2.1.0 pushed as the latest for longer than was healthy given the
>>>> artifact
>>>>>> signing issues. As a user it also gives me more confidence that once I
>>>> see
>>>>>> a new release transition to stable (say 6 weeks) or recommended (say 3
>>>>>> months) that I am following the project guidelines
>>>>>>
>>>>>> I am not saying the version would be missing (the tag would always be
>>>>>> there) but that a binary or source dist would not...
>>>>>>
>>>>>> Everyone is entitled to their opinion... previously it was Maven
>>>> developers
>>>>>> who said no missing version... Iirc you are the first to suggest users
>>>>>> would be confused.... Have we actually asked users which is more
>>>> confusing?
>>>>
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> --
>>> Sent from my phone
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Stephen Connolly <st...@gmail.com>.
Another data point is exactly how many times have we got patch release .0 right?
2.1.0 - seriously borked use 2.2.1
2.2.0 - seriously borked use 2.2.1
3.0.0-3.0.2 - not recommended for use
3.0.3 - ok but has issues with release plugin
3.0.4 - first 3.x that could be considered stable
3.1.0 - borked enough to recommend not for production IMHO
From experience I, as a PMC member, do not recommend my day job picking up a x.y.0 from Maven... So why should we hold patch numbers as special enough that they must increase by 1 between "blessed" releases *when we cannot even guarantee that a "blessed" release is ready for production?*
Maybe we should split this into another DISCUSS thread, though I am conscious that this subject is distracting from actually getting releases out the door... OTOH allowing skips in patch release numbers would allow work on core to continue without having to coordinate a "nobody commit to master while vote in play" policy which seems completely against how one should use GIT
Sent from my iPhone
On 15 Sep 2013, at 12:30, Fred Cooke <fr...@gmail.com> wrote:
> Exactly! :-)
>
>
> On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> But you asked the wrong jump then.
>>
>> It would be 3.0.5 to 4.0.4... There's no way we'd skip 4.0.x to go to 4.1.x
>> if we have not had a 4.0.x released at all.
>>
>> My point is patch version people are perfectly fine with skips.... Minor
>> version skips would be bad, but there is zero need for them.
>>
>> On Sunday, 15 September 2013, Robert Scholte wrote:
>>
>>> That someone might have been me.
>>> I did an internal poll to ask if people would understand if Maven would
>>> jump from 3.0.5 to 4.1.3.
>>> None of them did, they all wondered what happened to the missing
>> versions.
>>> Sure they understand that 4.1.3 is newer than 3.0.5, these aren't morons.
>>>
>>> One major difference is that Maven can't update itself to the latest
>>> version. If that would be the case, then versions are only interesting to
>>> reproduce issues and people often wouldn't see/matter the version.
>>>
>>> *If* we would allow gaps, we should also introduce LTS releases.
>>>
>>> For now, I'd prefer reusing versions and no gaps. I don't mind deleting
>>> tags, otherwise I'd prefer the usage of RCx during votes.
>>>
>>> Robert
>>>
>>> Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke <
>>> fred.cooke@gmail.com>:
>>>
>>> Last time someone asked this I went straight to central and found two
>>> examples. There are plenty out there. I'm not doing it again, you're more
>>> than capable. Also note, it's not much different to go from 3.1.2 to
>> 3.1.4
>>> than it is from 3.1.5 to 3.2.0; you still miss out versions, an infinite
>>> number of them, in fact.
>>>
>>> Preferring not to have gaps is a choice and one I was aware you lot would
>>> make. That's why I didn't bring it up in the first place despite
>> preferring
>>> to just straight miss them. Or just straight publish all releases (as is
>>> normal mvn practice since forever) and direct users to the ones that
>>> work... I *think* this is what Stephen is trying to say, but if I'm
>> honest
>>> I missed out a lot of what he wrote. Forgive me, it's 2am here.
>>>
>>>
>>> On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl <ja...@tesla.io> wrote:
>>>
>>> The users may well be developers, but I don't think that warrants
>> changing
>>> a normal pattern. Maybe only I consider this a normal pattern, but I
>> don't
>>> know of any examples, personally, where externally represented versions
>>> have gaps in them. I'd ask you the same question I asked Stephen as to
>>> whether you know of any projects, or products, that do this? Just because
>>> we can skip versions isn't a good reason to do so. If lots of projects do
>>> it then it's worth considering. Have any examples on hand?
>>>
>>> For now while I'm doing the core releases, I would prefer not to have
>>> gaps. Call me provincial, but I'd like to do what we've always done since
>>> the inception of the project unless there is a compelling reason to do
>>> otherwise.
>>>
>>> On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
>>>
>>>> Jason, PLEASE understand that you do NOT have a single user. Not even
>>> one.
>>>> Nada. Zilch. You have developers. Developers, by definition, are not
>>>> *completely* stupid (though some try to fool us!). They can handle
>>> missing
>>>> versions. If you released firefox 12 after firefox 10 it would be
>>> confusing
>>>> for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
>>>> moron would be confused by this. Few developers are that stupid, and
>>> those
>>>> who are have limited months of career as a dev ahead of them. "it's
>>>> confusing" holds no water in the context of a hard-core dev tool IMO.
>>>>
>>>>
>>>> On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>
>>>>> The difference is that you say those versions did not pass QA.
>>>>>
>>>>> As a user I'd rather know that what I have *unabiguously* passed QA
>>>>> (whatever that QA process is, and however lax it is) than know the
>>>>> increasing version numbers. On top of that, if we go increasing, with
>> no
>>>>> skips, we are actually giving people a false sense of extra QA... By
>>>>> telling people "go to this page where we list the status of each
>>> version"
>>>>> then they will not be confused at all... Instead they get greater
>>>>> confidence...
>>>>>
>>>>> They will see
>>>>>
>>>>> * some versions we never released a binary for... Those were really
>> bad
>>>>>
>>>>> * some versions we released a binary for... And then found critical
>>> bugs is
>>>>>
>>>>> * some versions we released a binary for, but its only recent so there
>>>>> could be regressions our test suite missed
>>>>>
>>>>> * some versions we reased a binary for, have had no serious issues
>>> raised
>>>>> for the past 6 weeks and are considered stable
>>>>>
>>>>> * some versions we no longer recommend
>>>>>
>>>>> As a user such a page gives me much more confidence in the project
>>> rather
>>>>> than our current "every release is a release" lase fair attitude that
>>> saw
>>>>> 2.1.0 pushed as the latest for longer than was healthy given the
>>> artifact
>>>>> signing issues. As a user it also gives me more confidence that once I
>>> see
>>>>> a new release transition to stable (say 6 weeks) or recommended (say 3
>>>>> months) that I am following the project guidelines
>>>>>
>>>>> I am not saying the version would be missing (the tag would always be
>>>>> there) but that a binary or source dist would not...
>>>>>
>>>>> Everyone is entitled to their opinion... previously it was Maven
>>> developers
>>>>> who said no missing version... Iirc you are the first to suggest users
>>>>> would be confused.... Have we actually asked users which is more
>>> confusing?
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> --
>> Sent from my phone
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
Exactly! :-)
On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> But you asked the wrong jump then.
>
> It would be 3.0.5 to 4.0.4... There's no way we'd skip 4.0.x to go to 4.1.x
> if we have not had a 4.0.x released at all.
>
> My point is patch version people are perfectly fine with skips.... Minor
> version skips would be bad, but there is zero need for them.
>
> On Sunday, 15 September 2013, Robert Scholte wrote:
>
> > That someone might have been me.
> > I did an internal poll to ask if people would understand if Maven would
> > jump from 3.0.5 to 4.1.3.
> > None of them did, they all wondered what happened to the missing
> versions.
> > Sure they understand that 4.1.3 is newer than 3.0.5, these aren't morons.
> >
> > One major difference is that Maven can't update itself to the latest
> > version. If that would be the case, then versions are only interesting to
> > reproduce issues and people often wouldn't see/matter the version.
> >
> > *If* we would allow gaps, we should also introduce LTS releases.
> >
> > For now, I'd prefer reusing versions and no gaps. I don't mind deleting
> > tags, otherwise I'd prefer the usage of RCx during votes.
> >
> > Robert
> >
> > Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke <
> > fred.cooke@gmail.com>:
> >
> > Last time someone asked this I went straight to central and found two
> > examples. There are plenty out there. I'm not doing it again, you're more
> > than capable. Also note, it's not much different to go from 3.1.2 to
> 3.1.4
> > than it is from 3.1.5 to 3.2.0; you still miss out versions, an infinite
> > number of them, in fact.
> >
> > Preferring not to have gaps is a choice and one I was aware you lot would
> > make. That's why I didn't bring it up in the first place despite
> preferring
> > to just straight miss them. Or just straight publish all releases (as is
> > normal mvn practice since forever) and direct users to the ones that
> > work... I *think* this is what Stephen is trying to say, but if I'm
> honest
> > I missed out a lot of what he wrote. Forgive me, it's 2am here.
> >
> >
> > On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl <ja...@tesla.io> wrote:
> >
> > The users may well be developers, but I don't think that warrants
> changing
> > a normal pattern. Maybe only I consider this a normal pattern, but I
> don't
> > know of any examples, personally, where externally represented versions
> > have gaps in them. I'd ask you the same question I asked Stephen as to
> > whether you know of any projects, or products, that do this? Just because
> > we can skip versions isn't a good reason to do so. If lots of projects do
> > it then it's worth considering. Have any examples on hand?
> >
> > For now while I'm doing the core releases, I would prefer not to have
> > gaps. Call me provincial, but I'd like to do what we've always done since
> > the inception of the project unless there is a compelling reason to do
> > otherwise.
> >
> > On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
> >
> > > Jason, PLEASE understand that you do NOT have a single user. Not even
> > one.
> > > Nada. Zilch. You have developers. Developers, by definition, are not
> > > *completely* stupid (though some try to fool us!). They can handle
> > missing
> > > versions. If you released firefox 12 after firefox 10 it would be
> > confusing
> > > for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
> > > moron would be confused by this. Few developers are that stupid, and
> > those
> > > who are have limited months of career as a dev ahead of them. "it's
> > > confusing" holds no water in the context of a hard-core dev tool IMO.
> > >
> > >
> > > On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
> > > stephen.alan.connolly@gmail.com> wrote:
> > >
> > >> The difference is that you say those versions did not pass QA.
> > >>
> > >> As a user I'd rather know that what I have *unabiguously* passed QA
> > >> (whatever that QA process is, and however lax it is) than know the
> > >> increasing version numbers. On top of that, if we go increasing, with
> no
> > >> skips, we are actually giving people a false sense of extra QA... By
> > >> telling people "go to this page where we list the status of each
> > version"
> > >> then they will not be confused at all... Instead they get greater
> > >> confidence...
> > >>
> > >> They will see
> > >>
> > >> * some versions we never released a binary for... Those were really
> bad
> > >>
> > >> * some versions we released a binary for... And then found critical
> > bugs is
> > >>
> > >> * some versions we released a binary for, but its only recent so there
> > >> could be regressions our test suite missed
> > >>
> > >> * some versions we reased a binary for, have had no serious issues
> > raised
> > >> for the past 6 weeks and are considered stable
> > >>
> > >> * some versions we no longer recommend
> > >>
> > >> As a user such a page gives me much more confidence in the project
> > rather
> > >> than our current "every release is a release" lase fair attitude that
> > saw
> > >> 2.1.0 pushed as the latest for longer than was healthy given the
> > artifact
> > >> signing issues. As a user it also gives me more confidence that once I
> > see
> > >> a new release transition to stable (say 6 weeks) or recommended (say 3
> > >> months) that I am following the project guidelines
> > >>
> > >> I am not saying the version would be missing (the tag would always be
> > >> there) but that a binary or source dist would not...
> > >>
> > >> Everyone is entitled to their opinion... previously it was Maven
> > developers
> > >> who said no missing version... Iirc you are the first to suggest users
> > >> would be confused.... Have we actually asked users which is more
> > confusing?
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> Sent from my phone
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Stephen Connolly <st...@gmail.com>.
But you asked the wrong jump then.
It would be 3.0.5 to 4.0.4... There's no way we'd skip 4.0.x to go to 4.1.x
if we have not had a 4.0.x released at all.
My point is patch version people are perfectly fine with skips.... Minor
version skips would be bad, but there is zero need for them.
On Sunday, 15 September 2013, Robert Scholte wrote:
> That someone might have been me.
> I did an internal poll to ask if people would understand if Maven would
> jump from 3.0.5 to 4.1.3.
> None of them did, they all wondered what happened to the missing versions.
> Sure they understand that 4.1.3 is newer than 3.0.5, these aren't morons.
>
> One major difference is that Maven can't update itself to the latest
> version. If that would be the case, then versions are only interesting to
> reproduce issues and people often wouldn't see/matter the version.
>
> *If* we would allow gaps, we should also introduce LTS releases.
>
> For now, I'd prefer reusing versions and no gaps. I don't mind deleting
> tags, otherwise I'd prefer the usage of RCx during votes.
>
> Robert
>
> Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke <
> fred.cooke@gmail.com>:
>
> Last time someone asked this I went straight to central and found two
> examples. There are plenty out there. I'm not doing it again, you're more
> than capable. Also note, it's not much different to go from 3.1.2 to 3.1.4
> than it is from 3.1.5 to 3.2.0; you still miss out versions, an infinite
> number of them, in fact.
>
> Preferring not to have gaps is a choice and one I was aware you lot would
> make. That's why I didn't bring it up in the first place despite preferring
> to just straight miss them. Or just straight publish all releases (as is
> normal mvn practice since forever) and direct users to the ones that
> work... I *think* this is what Stephen is trying to say, but if I'm honest
> I missed out a lot of what he wrote. Forgive me, it's 2am here.
>
>
> On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl <ja...@tesla.io> wrote:
>
> The users may well be developers, but I don't think that warrants changing
> a normal pattern. Maybe only I consider this a normal pattern, but I don't
> know of any examples, personally, where externally represented versions
> have gaps in them. I'd ask you the same question I asked Stephen as to
> whether you know of any projects, or products, that do this? Just because
> we can skip versions isn't a good reason to do so. If lots of projects do
> it then it's worth considering. Have any examples on hand?
>
> For now while I'm doing the core releases, I would prefer not to have
> gaps. Call me provincial, but I'd like to do what we've always done since
> the inception of the project unless there is a compelling reason to do
> otherwise.
>
> On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
>
> > Jason, PLEASE understand that you do NOT have a single user. Not even
> one.
> > Nada. Zilch. You have developers. Developers, by definition, are not
> > *completely* stupid (though some try to fool us!). They can handle
> missing
> > versions. If you released firefox 12 after firefox 10 it would be
> confusing
> > for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
> > moron would be confused by this. Few developers are that stupid, and
> those
> > who are have limited months of career as a dev ahead of them. "it's
> > confusing" holds no water in the context of a hard-core dev tool IMO.
> >
> >
> > On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> >> The difference is that you say those versions did not pass QA.
> >>
> >> As a user I'd rather know that what I have *unabiguously* passed QA
> >> (whatever that QA process is, and however lax it is) than know the
> >> increasing version numbers. On top of that, if we go increasing, with no
> >> skips, we are actually giving people a false sense of extra QA... By
> >> telling people "go to this page where we list the status of each
> version"
> >> then they will not be confused at all... Instead they get greater
> >> confidence...
> >>
> >> They will see
> >>
> >> * some versions we never released a binary for... Those were really bad
> >>
> >> * some versions we released a binary for... And then found critical
> bugs is
> >>
> >> * some versions we released a binary for, but its only recent so there
> >> could be regressions our test suite missed
> >>
> >> * some versions we reased a binary for, have had no serious issues
> raised
> >> for the past 6 weeks and are considered stable
> >>
> >> * some versions we no longer recommend
> >>
> >> As a user such a page gives me much more confidence in the project
> rather
> >> than our current "every release is a release" lase fair attitude that
> saw
> >> 2.1.0 pushed as the latest for longer than was healthy given the
> artifact
> >> signing issues. As a user it also gives me more confidence that once I
> see
> >> a new release transition to stable (say 6 weeks) or recommended (say 3
> >> months) that I am following the project guidelines
> >>
> >> I am not saying the version would be missing (the tag would always be
> >> there) but that a binary or source dist would not...
> >>
> >> Everyone is entitled to their opinion... previously it was Maven
> developers
> >> who said no missing version... Iirc you are the first to suggest users
> >> would be confused.... Have we actually asked users which is more
> confusing?
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Robert Scholte <rf...@apache.org>.
That someone might have been me.
I did an internal poll to ask if people would understand if Maven would
jump from 3.0.5 to 4.1.3.
None of them did, they all wondered what happened to the missing versions.
Sure they understand that 4.1.3 is newer than 3.0.5, these aren't morons.
One major difference is that Maven can't update itself to the latest
version. If that would be the case, then versions are only interesting to
reproduce issues and people often wouldn't see/matter the version.
*If* we would allow gaps, we should also introduce LTS releases.
For now, I'd prefer reusing versions and no gaps. I don't mind deleting
tags, otherwise I'd prefer the usage of RCx during votes.
Robert
Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke
<fr...@gmail.com>:
> Last time someone asked this I went straight to central and found two
> examples. There are plenty out there. I'm not doing it again, you're more
> than capable. Also note, it's not much different to go from 3.1.2 to
> 3.1.4
> than it is from 3.1.5 to 3.2.0; you still miss out versions, an infinite
> number of them, in fact.
>
> Preferring not to have gaps is a choice and one I was aware you lot would
> make. That's why I didn't bring it up in the first place despite
> preferring
> to just straight miss them. Or just straight publish all releases (as is
> normal mvn practice since forever) and direct users to the ones that
> work... I *think* this is what Stephen is trying to say, but if I'm
> honest
> I missed out a lot of what he wrote. Forgive me, it's 2am here.
>
>
> On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl <ja...@tesla.io> wrote:
>
>> The users may well be developers, but I don't think that warrants
>> changing
>> a normal pattern. Maybe only I consider this a normal pattern, but I
>> don't
>> know of any examples, personally, where externally represented versions
>> have gaps in them. I'd ask you the same question I asked Stephen as to
>> whether you know of any projects, or products, that do this? Just
>> because
>> we can skip versions isn't a good reason to do so. If lots of projects
>> do
>> it then it's worth considering. Have any examples on hand?
>>
>> For now while I'm doing the core releases, I would prefer not to have
>> gaps. Call me provincial, but I'd like to do what we've always done
>> since
>> the inception of the project unless there is a compelling reason to do
>> otherwise.
>>
>> On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
>>
>> > Jason, PLEASE understand that you do NOT have a single user. Not even
>> one.
>> > Nada. Zilch. You have developers. Developers, by definition, are not
>> > *completely* stupid (though some try to fool us!). They can handle
>> missing
>> > versions. If you released firefox 12 after firefox 10 it would be
>> confusing
>> > for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
>> > moron would be confused by this. Few developers are that stupid, and
>> those
>> > who are have limited months of career as a dev ahead of them. "it's
>> > confusing" holds no water in the context of a hard-core dev tool IMO.
>> >
>> >
>> > On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
>> > stephen.alan.connolly@gmail.com> wrote:
>> >
>> >> The difference is that you say those versions did not pass QA.
>> >>
>> >> As a user I'd rather know that what I have *unabiguously* passed QA
>> >> (whatever that QA process is, and however lax it is) than know the
>> >> increasing version numbers. On top of that, if we go increasing,
>> with no
>> >> skips, we are actually giving people a false sense of extra QA... By
>> >> telling people "go to this page where we list the status of each
>> version"
>> >> then they will not be confused at all... Instead they get greater
>> >> confidence...
>> >>
>> >> They will see
>> >>
>> >> * some versions we never released a binary for... Those were really
>> bad
>> >>
>> >> * some versions we released a binary for... And then found critical
>> bugs is
>> >>
>> >> * some versions we released a binary for, but its only recent so
>> there
>> >> could be regressions our test suite missed
>> >>
>> >> * some versions we reased a binary for, have had no serious issues
>> raised
>> >> for the past 6 weeks and are considered stable
>> >>
>> >> * some versions we no longer recommend
>> >>
>> >> As a user such a page gives me much more confidence in the project
>> rather
>> >> than our current "every release is a release" lase fair attitude that
>> saw
>> >> 2.1.0 pushed as the latest for longer than was healthy given the
>> artifact
>> >> signing issues. As a user it also gives me more confidence that once
>> I
>> see
>> >> a new release transition to stable (say 6 weeks) or recommended (say
>> 3
>> >> months) that I am following the project guidelines
>> >>
>> >> I am not saying the version would be missing (the tag would always be
>> >> there) but that a binary or source dist would not...
>> >>
>> >> Everyone is entitled to their opinion... previously it was Maven
>> developers
>> >> who said no missing version... Iirc you are the first to suggest
>> users
>> >> would be confused.... Have we actually asked users which is more
>> confusing?
>> >>
>> >> On Saturday, 14 September 2013, Jason van Zyl wrote:
>> >>
>> >>> I don't agree. I think this would be massively confusing to people
>> if a
>> >>> version was missing, or several failed and you went from 3.1.0 to
>> 3.1.3.
>> >> I
>> >>> don't think that would make much sense to most users.
>> >>>
>> >>> On Sep 14, 2013, at 5:49 PM, Stephen Connolly <
>> >>> stephen.alan.connolly@gmail.com> wrote:
>> >>>
>> >>>> On Saturday, 14 September 2013, Dennis Lundberg wrote:
>> >>>>
>> >>>>> JIRA is not a big problem. Say for example that the 3.1.1 release
>> was
>> >>>>> abandoned due to some problem, you would simply rename the
>> version in
>> >>>>> JIRA from 3.1.1 to 3.1.2.
>> >>>>
>> >>>>
>> >>>> Exactly.
>> >>>>
>> >>>> Not a problem if you ask me... The only one I can think of if the
>> >> javadoc
>> >>>> @since tags and even without skipping versions they can end up at a
>> >>>> unreleased version label, plus they are just a >= which will be
>> valid
>> >>> anyway
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg
>> <st...@yahoo.de>
>> >>> wrote:
>> >>>>>> I think it's mainly because the maintenance and housekeeping
>> costs
>> on
>> >>>>> the JIRA front and others which use the version nr as reference.
>> >>>>>>
>> >>>>>>
>> >>>>>> Imagine that you would need to move all the JIRA tickets which
>> got
>> >>>>> marked as fixed in a certain release as well. Otherwise the
>> release
>> >>> notes
>> >>>>> would be broken - or would need to get maintained manually.
>> >>>>>>
>> >>>>>>
>> >>>>>> LieGrue,
>> >>>>>> strub
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> ----- Original Message -----
>> >>>>>>> From: Fred Cooke <fr...@gmail.com>
>> >>>>>>> To: Maven Developers List <de...@maven.apache.org>
>> >>>>>>> Cc:
>> >>>>>>> Sent: Saturday, 14 September 2013, 21:51
>> >>>>>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>> >>>>>>>
>> >>>>>>> I agree on skipping failed versions! I was avoiding the topic
>> >> because
>> >>> it
>> >>>>>>> seemed popular opinion was to re-spin endlessly like a child's
>> >>> spinning
>> >>>>> top.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
>> >>>>>>> stephen.alan.connolly@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>>> Why as long as you don't push the tag, there's no big deal.
>> Pushing
>> >>>>>>> the tag
>> >>>>>>>> is when problems appear... In any case I'd prefer to just skip
>> >> failed
>> >>>>>>>> version numbers... Though I was voted down last time that came
>> up,
>> >>> and
>> >>>>>>>> given I'm not running too many releases at the moment, I don't
>> see
>> >>>>>>> my
>> >>>>>>>> opinion as being heavyweight on that subject... Version numbers
>> are
>> >>>>> cheap
>> >>>>>>>> and we've had borked releases before (eg critical IMHO bugs in
>> >> 2.1.0,
>> >>>>>>> 2.2.0
>> >>>>>>>> and 3.1.0...) so I don't buy the "what if a user checks out a
>> tag
>> >>>>>>> that was
>> >>>>>>>> not released" argument.
>> >>>>>>>>
>> >>>>>>>> In my opinion we need a release status page anyway, eg stating
>> >>> whether
>> >>>>>>>> specific versions are considered stabilising, stable, retired
>> or
>> >>>>> advised
>> >>>>>>>> not to be used... Such a page would remove the need for
>> recycling
>> >>>>> version
>> >>>>>>>> numbers *and* provide benefit to users at the same time.
>> >>>>>>>>
>> >>>>>>>> But I will leave it for others to fight the relative costs of
>> >> version
>> >>>>>>>> numbers (given the infinite supply) against making sure JIRA
>> >> release
>> >>>>> notes
>> >>>>>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
>> >>>>> should be
>> >>>>>>>> there in the 3.3.0 release that 3.2.3 became, so no fix
>> strictly
>> >>>>>>>> required) are correct and saving the risk that a user checks
>> out
>> an
>> >>>>>>>> unreleased tag and tries to build that from source and then
>> starts
>> >>>>> trying
>> >>>>>>>> to raise bugs against a non-exist any version!
>> >>>>>>>>
>> >>>>>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>> >>>>>>>>
>> >>>>>>>>> We need a slight modification of this strategy because the
>> changes
>> >>>>>>> need
>> >>>>>>>> to
>> >>>>>>>>> be pushed somewhere so that people can examine the tag if they
>> >> want
>> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> <javascript:;><javascript:;>
>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> <javascript:;><javascript:;>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> --
>> >>>> Sent from my phone
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Jason
>> >>>
>> >>> ----------------------------------------------------------
>> >>> Jason van Zyl
>> >>> Founder, Apache Maven
>> >>> http://twitter.com/jvanzyl
>> >>> ---------------------------------------------------------
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> Sent from my phone
>> >>
>>
>> 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
Last time someone asked this I went straight to central and found two
examples. There are plenty out there. I'm not doing it again, you're more
than capable. Also note, it's not much different to go from 3.1.2 to 3.1.4
than it is from 3.1.5 to 3.2.0; you still miss out versions, an infinite
number of them, in fact.
Preferring not to have gaps is a choice and one I was aware you lot would
make. That's why I didn't bring it up in the first place despite preferring
to just straight miss them. Or just straight publish all releases (as is
normal mvn practice since forever) and direct users to the ones that
work... I *think* this is what Stephen is trying to say, but if I'm honest
I missed out a lot of what he wrote. Forgive me, it's 2am here.
On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl <ja...@tesla.io> wrote:
> The users may well be developers, but I don't think that warrants changing
> a normal pattern. Maybe only I consider this a normal pattern, but I don't
> know of any examples, personally, where externally represented versions
> have gaps in them. I'd ask you the same question I asked Stephen as to
> whether you know of any projects, or products, that do this? Just because
> we can skip versions isn't a good reason to do so. If lots of projects do
> it then it's worth considering. Have any examples on hand?
>
> For now while I'm doing the core releases, I would prefer not to have
> gaps. Call me provincial, but I'd like to do what we've always done since
> the inception of the project unless there is a compelling reason to do
> otherwise.
>
> On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
>
> > Jason, PLEASE understand that you do NOT have a single user. Not even
> one.
> > Nada. Zilch. You have developers. Developers, by definition, are not
> > *completely* stupid (though some try to fool us!). They can handle
> missing
> > versions. If you released firefox 12 after firefox 10 it would be
> confusing
> > for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
> > moron would be confused by this. Few developers are that stupid, and
> those
> > who are have limited months of career as a dev ahead of them. "it's
> > confusing" holds no water in the context of a hard-core dev tool IMO.
> >
> >
> > On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> >> The difference is that you say those versions did not pass QA.
> >>
> >> As a user I'd rather know that what I have *unabiguously* passed QA
> >> (whatever that QA process is, and however lax it is) than know the
> >> increasing version numbers. On top of that, if we go increasing, with no
> >> skips, we are actually giving people a false sense of extra QA... By
> >> telling people "go to this page where we list the status of each
> version"
> >> then they will not be confused at all... Instead they get greater
> >> confidence...
> >>
> >> They will see
> >>
> >> * some versions we never released a binary for... Those were really bad
> >>
> >> * some versions we released a binary for... And then found critical
> bugs is
> >>
> >> * some versions we released a binary for, but its only recent so there
> >> could be regressions our test suite missed
> >>
> >> * some versions we reased a binary for, have had no serious issues
> raised
> >> for the past 6 weeks and are considered stable
> >>
> >> * some versions we no longer recommend
> >>
> >> As a user such a page gives me much more confidence in the project
> rather
> >> than our current "every release is a release" lase fair attitude that
> saw
> >> 2.1.0 pushed as the latest for longer than was healthy given the
> artifact
> >> signing issues. As a user it also gives me more confidence that once I
> see
> >> a new release transition to stable (say 6 weeks) or recommended (say 3
> >> months) that I am following the project guidelines
> >>
> >> I am not saying the version would be missing (the tag would always be
> >> there) but that a binary or source dist would not...
> >>
> >> Everyone is entitled to their opinion... previously it was Maven
> developers
> >> who said no missing version... Iirc you are the first to suggest users
> >> would be confused.... Have we actually asked users which is more
> confusing?
> >>
> >> On Saturday, 14 September 2013, Jason van Zyl wrote:
> >>
> >>> I don't agree. I think this would be massively confusing to people if a
> >>> version was missing, or several failed and you went from 3.1.0 to
> 3.1.3.
> >> I
> >>> don't think that would make much sense to most users.
> >>>
> >>> On Sep 14, 2013, at 5:49 PM, Stephen Connolly <
> >>> stephen.alan.connolly@gmail.com> wrote:
> >>>
> >>>> On Saturday, 14 September 2013, Dennis Lundberg wrote:
> >>>>
> >>>>> JIRA is not a big problem. Say for example that the 3.1.1 release was
> >>>>> abandoned due to some problem, you would simply rename the version in
> >>>>> JIRA from 3.1.1 to 3.1.2.
> >>>>
> >>>>
> >>>> Exactly.
> >>>>
> >>>> Not a problem if you ask me... The only one I can think of if the
> >> javadoc
> >>>> @since tags and even without skipping versions they can end up at a
> >>>> unreleased version label, plus they are just a >= which will be valid
> >>> anyway
> >>>>
> >>>>
> >>>>>
> >>>>> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de>
> >>> wrote:
> >>>>>> I think it's mainly because the maintenance and housekeeping costs
> on
> >>>>> the JIRA front and others which use the version nr as reference.
> >>>>>>
> >>>>>>
> >>>>>> Imagine that you would need to move all the JIRA tickets which got
> >>>>> marked as fixed in a certain release as well. Otherwise the release
> >>> notes
> >>>>> would be broken - or would need to get maintained manually.
> >>>>>>
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: Fred Cooke <fr...@gmail.com>
> >>>>>>> To: Maven Developers List <de...@maven.apache.org>
> >>>>>>> Cc:
> >>>>>>> Sent: Saturday, 14 September 2013, 21:51
> >>>>>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >>>>>>>
> >>>>>>> I agree on skipping failed versions! I was avoiding the topic
> >> because
> >>> it
> >>>>>>> seemed popular opinion was to re-spin endlessly like a child's
> >>> spinning
> >>>>> top.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
> >>>>>>> stephen.alan.connolly@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> Why as long as you don't push the tag, there's no big deal.
> Pushing
> >>>>>>> the tag
> >>>>>>>> is when problems appear... In any case I'd prefer to just skip
> >> failed
> >>>>>>>> version numbers... Though I was voted down last time that came up,
> >>> and
> >>>>>>>> given I'm not running too many releases at the moment, I don't see
> >>>>>>> my
> >>>>>>>> opinion as being heavyweight on that subject... Version numbers
> are
> >>>>> cheap
> >>>>>>>> and we've had borked releases before (eg critical IMHO bugs in
> >> 2.1.0,
> >>>>>>> 2.2.0
> >>>>>>>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
> >>>>>>> that was
> >>>>>>>> not released" argument.
> >>>>>>>>
> >>>>>>>> In my opinion we need a release status page anyway, eg stating
> >>> whether
> >>>>>>>> specific versions are considered stabilising, stable, retired or
> >>>>> advised
> >>>>>>>> not to be used... Such a page would remove the need for recycling
> >>>>> version
> >>>>>>>> numbers *and* provide benefit to users at the same time.
> >>>>>>>>
> >>>>>>>> But I will leave it for others to fight the relative costs of
> >> version
> >>>>>>>> numbers (given the infinite supply) against making sure JIRA
> >> release
> >>>>> notes
> >>>>>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
> >>>>> should be
> >>>>>>>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
> >>>>>>>> required) are correct and saving the risk that a user checks out
> an
> >>>>>>>> unreleased tag and tries to build that from source and then starts
> >>>>> trying
> >>>>>>>> to raise bugs against a non-exist any version!
> >>>>>>>>
> >>>>>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
> >>>>>>>>
> >>>>>>>>> We need a slight modification of this strategy because the
> changes
> >>>>>>> need
> >>>>>>>> to
> >>>>>>>>> be pushed somewhere so that people can examine the tag if they
> >> want
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> <javascript:;><javascript:;>
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> <javascript:;><javascript:;>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Sent from my phone
> >>>
> >>> Thanks,
> >>>
> >>> Jason
> >>>
> >>> ----------------------------------------------------------
> >>> Jason van Zyl
> >>> Founder, Apache Maven
> >>> http://twitter.com/jvanzyl
> >>> ---------------------------------------------------------
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> Sent from my phone
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>
>
>
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Mirko Friedenhagen <mf...@gmail.com>.
Hello,
IMO as long as only patch-levels (micro-versiony) are skipped, no harm
should come from skipping.
Regards Mirko
--
Sent from my mobile
On Sep 15, 2013 1:03 PM, "Dennis Lundberg" <de...@apache.org> wrote:
> Hi
>
> I won't get into the debate as to which process is best at this time,
> as I think they both have merits and drawbacks. Until I'm convinced
> one way or the other I prefer to continue doing business as usual.
>
> Here are a couple of large open source projects that do not publish
> *distributions* of failed releases:
>
> Tomcat
> http://archive.apache.org/dist/tomcat/tomcat-7/
>
> Subversion
> http://archive.apache.org/dist/subversion/
>
>
> On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl <ja...@tesla.io> wrote:
> > The users may well be developers, but I don't think that warrants
> changing a normal pattern. Maybe only I consider this a normal pattern, but
> I don't know of any examples, personally, where externally represented
> versions have gaps in them. I'd ask you the same question I asked Stephen
> as to whether you know of any projects, or products, that do this? Just
> because we can skip versions isn't a good reason to do so. If lots of
> projects do it then it's worth considering. Have any examples on hand?
> >
> > For now while I'm doing the core releases, I would prefer not to have
> gaps. Call me provincial, but I'd like to do what we've always done since
> the inception of the project unless there is a compelling reason to do
> otherwise.
> >
> > On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
> >
> >> Jason, PLEASE understand that you do NOT have a single user. Not even
> one.
> >> Nada. Zilch. You have developers. Developers, by definition, are not
> >> *completely* stupid (though some try to fool us!). They can handle
> missing
> >> versions. If you released firefox 12 after firefox 10 it would be
> confusing
> >> for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
> >> moron would be confused by this. Few developers are that stupid, and
> those
> >> who are have limited months of career as a dev ahead of them. "it's
> >> confusing" holds no water in the context of a hard-core dev tool IMO.
> >>
> >>
> >> On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
> >> stephen.alan.connolly@gmail.com> wrote:
> >>
> >>> The difference is that you say those versions did not pass QA.
> >>>
> >>> As a user I'd rather know that what I have *unabiguously* passed QA
> >>> (whatever that QA process is, and however lax it is) than know the
> >>> increasing version numbers. On top of that, if we go increasing, with
> no
> >>> skips, we are actually giving people a false sense of extra QA... By
> >>> telling people "go to this page where we list the status of each
> version"
> >>> then they will not be confused at all... Instead they get greater
> >>> confidence...
> >>>
> >>> They will see
> >>>
> >>> * some versions we never released a binary for... Those were really bad
> >>>
> >>> * some versions we released a binary for... And then found critical
> bugs is
> >>>
> >>> * some versions we released a binary for, but its only recent so there
> >>> could be regressions our test suite missed
> >>>
> >>> * some versions we reased a binary for, have had no serious issues
> raised
> >>> for the past 6 weeks and are considered stable
> >>>
> >>> * some versions we no longer recommend
> >>>
> >>> As a user such a page gives me much more confidence in the project
> rather
> >>> than our current "every release is a release" lase fair attitude that
> saw
> >>> 2.1.0 pushed as the latest for longer than was healthy given the
> artifact
> >>> signing issues. As a user it also gives me more confidence that once I
> see
> >>> a new release transition to stable (say 6 weeks) or recommended (say 3
> >>> months) that I am following the project guidelines
> >>>
> >>> I am not saying the version would be missing (the tag would always be
> >>> there) but that a binary or source dist would not...
> >>>
> >>> Everyone is entitled to their opinion... previously it was Maven
> developers
> >>> who said no missing version... Iirc you are the first to suggest users
> >>> would be confused.... Have we actually asked users which is more
> confusing?
> >>>
> >>> On Saturday, 14 September 2013, Jason van Zyl wrote:
> >>>
> >>>> I don't agree. I think this would be massively confusing to people if
> a
> >>>> version was missing, or several failed and you went from 3.1.0 to
> 3.1.3.
> >>> I
> >>>> don't think that would make much sense to most users.
> >>>>
> >>>> On Sep 14, 2013, at 5:49 PM, Stephen Connolly <
> >>>> stephen.alan.connolly@gmail.com> wrote:
> >>>>
> >>>>> On Saturday, 14 September 2013, Dennis Lundberg wrote:
> >>>>>
> >>>>>> JIRA is not a big problem. Say for example that the 3.1.1 release
> was
> >>>>>> abandoned due to some problem, you would simply rename the version
> in
> >>>>>> JIRA from 3.1.1 to 3.1.2.
> >>>>>
> >>>>>
> >>>>> Exactly.
> >>>>>
> >>>>> Not a problem if you ask me... The only one I can think of if the
> >>> javadoc
> >>>>> @since tags and even without skipping versions they can end up at a
> >>>>> unreleased version label, plus they are just a >= which will be valid
> >>>> anyway
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de>
> >>>> wrote:
> >>>>>>> I think it's mainly because the maintenance and housekeeping costs
> on
> >>>>>> the JIRA front and others which use the version nr as reference.
> >>>>>>>
> >>>>>>>
> >>>>>>> Imagine that you would need to move all the JIRA tickets which got
> >>>>>> marked as fixed in a certain release as well. Otherwise the release
> >>>> notes
> >>>>>> would be broken - or would need to get maintained manually.
> >>>>>>>
> >>>>>>>
> >>>>>>> LieGrue,
> >>>>>>> strub
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: Fred Cooke <fr...@gmail.com>
> >>>>>>>> To: Maven Developers List <de...@maven.apache.org>
> >>>>>>>> Cc:
> >>>>>>>> Sent: Saturday, 14 September 2013, 21:51
> >>>>>>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >>>>>>>>
> >>>>>>>> I agree on skipping failed versions! I was avoiding the topic
> >>> because
> >>>> it
> >>>>>>>> seemed popular opinion was to re-spin endlessly like a child's
> >>>> spinning
> >>>>>> top.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
> >>>>>>>> stephen.alan.connolly@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> Why as long as you don't push the tag, there's no big deal.
> Pushing
> >>>>>>>> the tag
> >>>>>>>>> is when problems appear... In any case I'd prefer to just skip
> >>> failed
> >>>>>>>>> version numbers... Though I was voted down last time that came
> up,
> >>>> and
> >>>>>>>>> given I'm not running too many releases at the moment, I don't
> see
> >>>>>>>> my
> >>>>>>>>> opinion as being heavyweight on that subject... Version numbers
> are
> >>>>>> cheap
> >>>>>>>>> and we've had borked releases before (eg critical IMHO bugs in
> >>> 2.1.0,
> >>>>>>>> 2.2.0
> >>>>>>>>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
> >>>>>>>> that was
> >>>>>>>>> not released" argument.
> >>>>>>>>>
> >>>>>>>>> In my opinion we need a release status page anyway, eg stating
> >>>> whether
> >>>>>>>>> specific versions are considered stabilising, stable, retired or
> >>>>>> advised
> >>>>>>>>> not to be used... Such a page would remove the need for recycling
> >>>>>> version
> >>>>>>>>> numbers *and* provide benefit to users at the same time.
> >>>>>>>>>
> >>>>>>>>> But I will leave it for others to fight the relative costs of
> >>> version
> >>>>>>>>> numbers (given the infinite supply) against making sure JIRA
> >>> release
> >>>>>> notes
> >>>>>>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
> >>>>>> should be
> >>>>>>>>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
> >>>>>>>>> required) are correct and saving the risk that a user checks out
> an
> >>>>>>>>> unreleased tag and tries to build that from source and then
> starts
> >>>>>> trying
> >>>>>>>>> to raise bugs against a non-exist any version!
> >>>>>>>>>
> >>>>>>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
> >>>>>>>>>
> >>>>>>>>>> We need a slight modification of this strategy because the
> changes
> >>>>>>>> need
> >>>>>>>>> to
> >>>>>>>>>> be pushed somewhere so that people can examine the tag if they
> >>> want
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> <javascript:;><javascript:;>
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>> <javascript:;><javascript:;>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Sent from my phone
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jason
> >>>>
> >>>> ----------------------------------------------------------
> >>>> Jason van Zyl
> >>>> Founder, Apache Maven
> >>>> http://twitter.com/jvanzyl
> >>>> ---------------------------------------------------------
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Sent from my phone
> >>>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Dennis Lundberg <de...@apache.org>.
Hi
I won't get into the debate as to which process is best at this time,
as I think they both have merits and drawbacks. Until I'm convinced
one way or the other I prefer to continue doing business as usual.
Here are a couple of large open source projects that do not publish
*distributions* of failed releases:
Tomcat
http://archive.apache.org/dist/tomcat/tomcat-7/
Subversion
http://archive.apache.org/dist/subversion/
On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl <ja...@tesla.io> wrote:
> The users may well be developers, but I don't think that warrants changing a normal pattern. Maybe only I consider this a normal pattern, but I don't know of any examples, personally, where externally represented versions have gaps in them. I'd ask you the same question I asked Stephen as to whether you know of any projects, or products, that do this? Just because we can skip versions isn't a good reason to do so. If lots of projects do it then it's worth considering. Have any examples on hand?
>
> For now while I'm doing the core releases, I would prefer not to have gaps. Call me provincial, but I'd like to do what we've always done since the inception of the project unless there is a compelling reason to do otherwise.
>
> On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
>
>> Jason, PLEASE understand that you do NOT have a single user. Not even one.
>> Nada. Zilch. You have developers. Developers, by definition, are not
>> *completely* stupid (though some try to fool us!). They can handle missing
>> versions. If you released firefox 12 after firefox 10 it would be confusing
>> for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
>> moron would be confused by this. Few developers are that stupid, and those
>> who are have limited months of career as a dev ahead of them. "it's
>> confusing" holds no water in the context of a hard-core dev tool IMO.
>>
>>
>> On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> The difference is that you say those versions did not pass QA.
>>>
>>> As a user I'd rather know that what I have *unabiguously* passed QA
>>> (whatever that QA process is, and however lax it is) than know the
>>> increasing version numbers. On top of that, if we go increasing, with no
>>> skips, we are actually giving people a false sense of extra QA... By
>>> telling people "go to this page where we list the status of each version"
>>> then they will not be confused at all... Instead they get greater
>>> confidence...
>>>
>>> They will see
>>>
>>> * some versions we never released a binary for... Those were really bad
>>>
>>> * some versions we released a binary for... And then found critical bugs is
>>>
>>> * some versions we released a binary for, but its only recent so there
>>> could be regressions our test suite missed
>>>
>>> * some versions we reased a binary for, have had no serious issues raised
>>> for the past 6 weeks and are considered stable
>>>
>>> * some versions we no longer recommend
>>>
>>> As a user such a page gives me much more confidence in the project rather
>>> than our current "every release is a release" lase fair attitude that saw
>>> 2.1.0 pushed as the latest for longer than was healthy given the artifact
>>> signing issues. As a user it also gives me more confidence that once I see
>>> a new release transition to stable (say 6 weeks) or recommended (say 3
>>> months) that I am following the project guidelines
>>>
>>> I am not saying the version would be missing (the tag would always be
>>> there) but that a binary or source dist would not...
>>>
>>> Everyone is entitled to their opinion... previously it was Maven developers
>>> who said no missing version... Iirc you are the first to suggest users
>>> would be confused.... Have we actually asked users which is more confusing?
>>>
>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>>
>>>> I don't agree. I think this would be massively confusing to people if a
>>>> version was missing, or several failed and you went from 3.1.0 to 3.1.3.
>>> I
>>>> don't think that would make much sense to most users.
>>>>
>>>> On Sep 14, 2013, at 5:49 PM, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>
>>>>> On Saturday, 14 September 2013, Dennis Lundberg wrote:
>>>>>
>>>>>> JIRA is not a big problem. Say for example that the 3.1.1 release was
>>>>>> abandoned due to some problem, you would simply rename the version in
>>>>>> JIRA from 3.1.1 to 3.1.2.
>>>>>
>>>>>
>>>>> Exactly.
>>>>>
>>>>> Not a problem if you ask me... The only one I can think of if the
>>> javadoc
>>>>> @since tags and even without skipping versions they can end up at a
>>>>> unreleased version label, plus they are just a >= which will be valid
>>>> anyway
>>>>>
>>>>>
>>>>>>
>>>>>> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de>
>>>> wrote:
>>>>>>> I think it's mainly because the maintenance and housekeeping costs on
>>>>>> the JIRA front and others which use the version nr as reference.
>>>>>>>
>>>>>>>
>>>>>>> Imagine that you would need to move all the JIRA tickets which got
>>>>>> marked as fixed in a certain release as well. Otherwise the release
>>>> notes
>>>>>> would be broken - or would need to get maintained manually.
>>>>>>>
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: Fred Cooke <fr...@gmail.com>
>>>>>>>> To: Maven Developers List <de...@maven.apache.org>
>>>>>>>> Cc:
>>>>>>>> Sent: Saturday, 14 September 2013, 21:51
>>>>>>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>>>>>>>
>>>>>>>> I agree on skipping failed versions! I was avoiding the topic
>>> because
>>>> it
>>>>>>>> seemed popular opinion was to re-spin endlessly like a child's
>>>> spinning
>>>>>> top.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
>>>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Why as long as you don't push the tag, there's no big deal. Pushing
>>>>>>>> the tag
>>>>>>>>> is when problems appear... In any case I'd prefer to just skip
>>> failed
>>>>>>>>> version numbers... Though I was voted down last time that came up,
>>>> and
>>>>>>>>> given I'm not running too many releases at the moment, I don't see
>>>>>>>> my
>>>>>>>>> opinion as being heavyweight on that subject... Version numbers are
>>>>>> cheap
>>>>>>>>> and we've had borked releases before (eg critical IMHO bugs in
>>> 2.1.0,
>>>>>>>> 2.2.0
>>>>>>>>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
>>>>>>>> that was
>>>>>>>>> not released" argument.
>>>>>>>>>
>>>>>>>>> In my opinion we need a release status page anyway, eg stating
>>>> whether
>>>>>>>>> specific versions are considered stabilising, stable, retired or
>>>>>> advised
>>>>>>>>> not to be used... Such a page would remove the need for recycling
>>>>>> version
>>>>>>>>> numbers *and* provide benefit to users at the same time.
>>>>>>>>>
>>>>>>>>> But I will leave it for others to fight the relative costs of
>>> version
>>>>>>>>> numbers (given the infinite supply) against making sure JIRA
>>> release
>>>>>> notes
>>>>>>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
>>>>>> should be
>>>>>>>>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
>>>>>>>>> required) are correct and saving the risk that a user checks out an
>>>>>>>>> unreleased tag and tries to build that from source and then starts
>>>>>> trying
>>>>>>>>> to raise bugs against a non-exist any version!
>>>>>>>>>
>>>>>>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>>>>>>>>
>>>>>>>>>> We need a slight modification of this strategy because the changes
>>>>>>>> need
>>>>>>>>> to
>>>>>>>>>> be pushed somewhere so that people can examine the tag if they
>>> want
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> <javascript:;><javascript:;>
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> <javascript:;><javascript:;>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Sent from my phone
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Sent from my phone
>>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Jason van Zyl <ja...@tesla.io>.
The users may well be developers, but I don't think that warrants changing a normal pattern. Maybe only I consider this a normal pattern, but I don't know of any examples, personally, where externally represented versions have gaps in them. I'd ask you the same question I asked Stephen as to whether you know of any projects, or products, that do this? Just because we can skip versions isn't a good reason to do so. If lots of projects do it then it's worth considering. Have any examples on hand?
For now while I'm doing the core releases, I would prefer not to have gaps. Call me provincial, but I'd like to do what we've always done since the inception of the project unless there is a compelling reason to do otherwise.
On Sep 14, 2013, at 7:48 PM, Fred Cooke <fr...@gmail.com> wrote:
> Jason, PLEASE understand that you do NOT have a single user. Not even one.
> Nada. Zilch. You have developers. Developers, by definition, are not
> *completely* stupid (though some try to fool us!). They can handle missing
> versions. If you released firefox 12 after firefox 10 it would be confusing
> for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
> moron would be confused by this. Few developers are that stupid, and those
> who are have limited months of career as a dev ahead of them. "it's
> confusing" holds no water in the context of a hard-core dev tool IMO.
>
>
> On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> The difference is that you say those versions did not pass QA.
>>
>> As a user I'd rather know that what I have *unabiguously* passed QA
>> (whatever that QA process is, and however lax it is) than know the
>> increasing version numbers. On top of that, if we go increasing, with no
>> skips, we are actually giving people a false sense of extra QA... By
>> telling people "go to this page where we list the status of each version"
>> then they will not be confused at all... Instead they get greater
>> confidence...
>>
>> They will see
>>
>> * some versions we never released a binary for... Those were really bad
>>
>> * some versions we released a binary for... And then found critical bugs is
>>
>> * some versions we released a binary for, but its only recent so there
>> could be regressions our test suite missed
>>
>> * some versions we reased a binary for, have had no serious issues raised
>> for the past 6 weeks and are considered stable
>>
>> * some versions we no longer recommend
>>
>> As a user such a page gives me much more confidence in the project rather
>> than our current "every release is a release" lase fair attitude that saw
>> 2.1.0 pushed as the latest for longer than was healthy given the artifact
>> signing issues. As a user it also gives me more confidence that once I see
>> a new release transition to stable (say 6 weeks) or recommended (say 3
>> months) that I am following the project guidelines
>>
>> I am not saying the version would be missing (the tag would always be
>> there) but that a binary or source dist would not...
>>
>> Everyone is entitled to their opinion... previously it was Maven developers
>> who said no missing version... Iirc you are the first to suggest users
>> would be confused.... Have we actually asked users which is more confusing?
>>
>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>
>>> I don't agree. I think this would be massively confusing to people if a
>>> version was missing, or several failed and you went from 3.1.0 to 3.1.3.
>> I
>>> don't think that would make much sense to most users.
>>>
>>> On Sep 14, 2013, at 5:49 PM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>> On Saturday, 14 September 2013, Dennis Lundberg wrote:
>>>>
>>>>> JIRA is not a big problem. Say for example that the 3.1.1 release was
>>>>> abandoned due to some problem, you would simply rename the version in
>>>>> JIRA from 3.1.1 to 3.1.2.
>>>>
>>>>
>>>> Exactly.
>>>>
>>>> Not a problem if you ask me... The only one I can think of if the
>> javadoc
>>>> @since tags and even without skipping versions they can end up at a
>>>> unreleased version label, plus they are just a >= which will be valid
>>> anyway
>>>>
>>>>
>>>>>
>>>>> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de>
>>> wrote:
>>>>>> I think it's mainly because the maintenance and housekeeping costs on
>>>>> the JIRA front and others which use the version nr as reference.
>>>>>>
>>>>>>
>>>>>> Imagine that you would need to move all the JIRA tickets which got
>>>>> marked as fixed in a certain release as well. Otherwise the release
>>> notes
>>>>> would be broken - or would need to get maintained manually.
>>>>>>
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: Fred Cooke <fr...@gmail.com>
>>>>>>> To: Maven Developers List <de...@maven.apache.org>
>>>>>>> Cc:
>>>>>>> Sent: Saturday, 14 September 2013, 21:51
>>>>>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>>>>>>
>>>>>>> I agree on skipping failed versions! I was avoiding the topic
>> because
>>> it
>>>>>>> seemed popular opinion was to re-spin endlessly like a child's
>>> spinning
>>>>> top.
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
>>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>>
>>>>>>>> Why as long as you don't push the tag, there's no big deal. Pushing
>>>>>>> the tag
>>>>>>>> is when problems appear... In any case I'd prefer to just skip
>> failed
>>>>>>>> version numbers... Though I was voted down last time that came up,
>>> and
>>>>>>>> given I'm not running too many releases at the moment, I don't see
>>>>>>> my
>>>>>>>> opinion as being heavyweight on that subject... Version numbers are
>>>>> cheap
>>>>>>>> and we've had borked releases before (eg critical IMHO bugs in
>> 2.1.0,
>>>>>>> 2.2.0
>>>>>>>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
>>>>>>> that was
>>>>>>>> not released" argument.
>>>>>>>>
>>>>>>>> In my opinion we need a release status page anyway, eg stating
>>> whether
>>>>>>>> specific versions are considered stabilising, stable, retired or
>>>>> advised
>>>>>>>> not to be used... Such a page would remove the need for recycling
>>>>> version
>>>>>>>> numbers *and* provide benefit to users at the same time.
>>>>>>>>
>>>>>>>> But I will leave it for others to fight the relative costs of
>> version
>>>>>>>> numbers (given the infinite supply) against making sure JIRA
>> release
>>>>> notes
>>>>>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
>>>>> should be
>>>>>>>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
>>>>>>>> required) are correct and saving the risk that a user checks out an
>>>>>>>> unreleased tag and tries to build that from source and then starts
>>>>> trying
>>>>>>>> to raise bugs against a non-exist any version!
>>>>>>>>
>>>>>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>>>>>>>
>>>>>>>>> We need a slight modification of this strategy because the changes
>>>>>>> need
>>>>>>>> to
>>>>>>>>> be pushed somewhere so that people can examine the tag if they
>> want
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> <javascript:;><javascript:;>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:;><javascript:;>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Sent from my phone
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Sent from my phone
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
Jason, PLEASE understand that you do NOT have a single user. Not even one.
Nada. Zilch. You have developers. Developers, by definition, are not
*completely* stupid (though some try to fool us!). They can handle missing
versions. If you released firefox 12 after firefox 10 it would be confusing
for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
moron would be confused by this. Few developers are that stupid, and those
who are have limited months of career as a dev ahead of them. "it's
confusing" holds no water in the context of a hard-core dev tool IMO.
On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> The difference is that you say those versions did not pass QA.
>
> As a user I'd rather know that what I have *unabiguously* passed QA
> (whatever that QA process is, and however lax it is) than know the
> increasing version numbers. On top of that, if we go increasing, with no
> skips, we are actually giving people a false sense of extra QA... By
> telling people "go to this page where we list the status of each version"
> then they will not be confused at all... Instead they get greater
> confidence...
>
> They will see
>
> * some versions we never released a binary for... Those were really bad
>
> * some versions we released a binary for... And then found critical bugs is
>
> * some versions we released a binary for, but its only recent so there
> could be regressions our test suite missed
>
> * some versions we reased a binary for, have had no serious issues raised
> for the past 6 weeks and are considered stable
>
> * some versions we no longer recommend
>
> As a user such a page gives me much more confidence in the project rather
> than our current "every release is a release" lase fair attitude that saw
> 2.1.0 pushed as the latest for longer than was healthy given the artifact
> signing issues. As a user it also gives me more confidence that once I see
> a new release transition to stable (say 6 weeks) or recommended (say 3
> months) that I am following the project guidelines
>
> I am not saying the version would be missing (the tag would always be
> there) but that a binary or source dist would not...
>
> Everyone is entitled to their opinion... previously it was Maven developers
> who said no missing version... Iirc you are the first to suggest users
> would be confused.... Have we actually asked users which is more confusing?
>
> On Saturday, 14 September 2013, Jason van Zyl wrote:
>
> > I don't agree. I think this would be massively confusing to people if a
> > version was missing, or several failed and you went from 3.1.0 to 3.1.3.
> I
> > don't think that would make much sense to most users.
> >
> > On Sep 14, 2013, at 5:49 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > On Saturday, 14 September 2013, Dennis Lundberg wrote:
> > >
> > >> JIRA is not a big problem. Say for example that the 3.1.1 release was
> > >> abandoned due to some problem, you would simply rename the version in
> > >> JIRA from 3.1.1 to 3.1.2.
> > >
> > >
> > > Exactly.
> > >
> > > Not a problem if you ask me... The only one I can think of if the
> javadoc
> > > @since tags and even without skipping versions they can end up at a
> > > unreleased version label, plus they are just a >= which will be valid
> > anyway
> > >
> > >
> > >>
> > >> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de>
> > wrote:
> > >>> I think it's mainly because the maintenance and housekeeping costs on
> > >> the JIRA front and others which use the version nr as reference.
> > >>>
> > >>>
> > >>> Imagine that you would need to move all the JIRA tickets which got
> > >> marked as fixed in a certain release as well. Otherwise the release
> > notes
> > >> would be broken - or would need to get maintained manually.
> > >>>
> > >>>
> > >>> LieGrue,
> > >>> strub
> > >>>
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: Fred Cooke <fr...@gmail.com>
> > >>>> To: Maven Developers List <de...@maven.apache.org>
> > >>>> Cc:
> > >>>> Sent: Saturday, 14 September 2013, 21:51
> > >>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> > >>>>
> > >>>> I agree on skipping failed versions! I was avoiding the topic
> because
> > it
> > >>>> seemed popular opinion was to re-spin endlessly like a child's
> > spinning
> > >> top.
> > >>>>
> > >>>>
> > >>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
> > >>>> stephen.alan.connolly@gmail.com> wrote:
> > >>>>
> > >>>>> Why as long as you don't push the tag, there's no big deal. Pushing
> > >>>> the tag
> > >>>>> is when problems appear... In any case I'd prefer to just skip
> failed
> > >>>>> version numbers... Though I was voted down last time that came up,
> > and
> > >>>>> given I'm not running too many releases at the moment, I don't see
> > >>>> my
> > >>>>> opinion as being heavyweight on that subject... Version numbers are
> > >> cheap
> > >>>>> and we've had borked releases before (eg critical IMHO bugs in
> 2.1.0,
> > >>>> 2.2.0
> > >>>>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
> > >>>> that was
> > >>>>> not released" argument.
> > >>>>>
> > >>>>> In my opinion we need a release status page anyway, eg stating
> > whether
> > >>>>> specific versions are considered stabilising, stable, retired or
> > >> advised
> > >>>>> not to be used... Such a page would remove the need for recycling
> > >> version
> > >>>>> numbers *and* provide benefit to users at the same time.
> > >>>>>
> > >>>>> But I will leave it for others to fight the relative costs of
> version
> > >>>>> numbers (given the infinite supply) against making sure JIRA
> release
> > >> notes
> > >>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
> > >> should be
> > >>>>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
> > >>>>> required) are correct and saving the risk that a user checks out an
> > >>>>> unreleased tag and tries to build that from source and then starts
> > >> trying
> > >>>>> to raise bugs against a non-exist any version!
> > >>>>>
> > >>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
> > >>>>>
> > >>>>>> We need a slight modification of this strategy because the changes
> > >>>> need
> > >>>>> to
> > >>>>>> be pushed somewhere so that people can examine the tag if they
> want
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;><javascript:;>
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;><javascript:;>
> > >>
> > >>
> > >
> > > --
> > > Sent from my phone
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Sent from my phone
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Jason van Zyl <ja...@tesla.io>.
On Sep 14, 2013, at 7:34 PM, Stephen Connolly <st...@gmail.com> wrote:
> The difference is that you say those versions did not pass QA.
>
I don't think that will alleviate the confusion, and trying to explain that will unlikely reach our audience and they will just be confused.
> As a user I'd rather know that what I have *unabiguously* passed QA
> (whatever that QA process is, and however lax it is) than know the
> increasing version numbers. On top of that, if we go increasing, with no
> skips, we are actually giving people a false sense of extra QA...
I think this is a fictional construction and is not what anyone has ever done with versions traditionally. In products or open source projects there are usually no gaps in the versions that are released. At least not in the marketing versions. If we had a stream of builds versioned by sha1 when there was success you give a version that is in sequence.
> By
> telling people "go to this page where we list the status of each version"
> then they will not be confused at all... Instead they get greater
> confidence...
I think that's conjecture and not my experience at all. They will not go to a page, they will see a gap and wonder if they missed something.
>
> They will see
>
> * some versions we never released a binary for... Those were really bad
>
> * some versions we released a binary for... And then found critical bugs is
>
> * some versions we released a binary for, but its only recent so there
> could be regressions our test suite missed
>
> * some versions we reased a binary for, have had no serious issues raised
> for the past 6 weeks and are considered stable
>
> * some versions we no longer recommend
>
> As a user such a page gives me much more confidence in the project rather
> than our current "every release is a release" lase fair attitude that saw
> 2.1.0 pushed as the latest for longer than was healthy given the artifact
> signing issues. As a user it also gives me more confidence that once I see
> a new release transition to stable (say 6 weeks) or recommended (say 3
> months) that I am following the project guidelines
>
> I am not saying the version would be missing (the tag would always be
> there) but that a binary or source dist would not...
>
> Everyone is entitled to their opinion... previously it was Maven developers
> who said no missing version... Iirc you are the first to suggest users
> would be confused.... Have we actually asked users which is more confusing?
>
Sure, we can ask them. I don't think users are interested in what happens internally and pay attention when releases actually happen. I don't think we're going to announce failed releases and so there. Do you know of any other projects that skip public versions on failed attempted releases? I don't.
> On Saturday, 14 September 2013, Jason van Zyl wrote:
>
>> I don't agree. I think this would be massively confusing to people if a
>> version was missing, or several failed and you went from 3.1.0 to 3.1.3. I
>> don't think that would make much sense to most users.
>>
>> On Sep 14, 2013, at 5:49 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> On Saturday, 14 September 2013, Dennis Lundberg wrote:
>>>
>>>> JIRA is not a big problem. Say for example that the 3.1.1 release was
>>>> abandoned due to some problem, you would simply rename the version in
>>>> JIRA from 3.1.1 to 3.1.2.
>>>
>>>
>>> Exactly.
>>>
>>> Not a problem if you ask me... The only one I can think of if the javadoc
>>> @since tags and even without skipping versions they can end up at a
>>> unreleased version label, plus they are just a >= which will be valid
>> anyway
>>>
>>>
>>>>
>>>> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de>
>> wrote:
>>>>> I think it's mainly because the maintenance and housekeeping costs on
>>>> the JIRA front and others which use the version nr as reference.
>>>>>
>>>>>
>>>>> Imagine that you would need to move all the JIRA tickets which got
>>>> marked as fixed in a certain release as well. Otherwise the release
>> notes
>>>> would be broken - or would need to get maintained manually.
>>>>>
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Fred Cooke <fr...@gmail.com>
>>>>>> To: Maven Developers List <de...@maven.apache.org>
>>>>>> Cc:
>>>>>> Sent: Saturday, 14 September 2013, 21:51
>>>>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>>>>>
>>>>>> I agree on skipping failed versions! I was avoiding the topic because
>> it
>>>>>> seemed popular opinion was to re-spin endlessly like a child's
>> spinning
>>>> top.
>>>>>>
>>>>>>
>>>>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>
>>>>>>> Why as long as you don't push the tag, there's no big deal. Pushing
>>>>>> the tag
>>>>>>> is when problems appear... In any case I'd prefer to just skip failed
>>>>>>> version numbers... Though I was voted down last time that came up,
>> and
>>>>>>> given I'm not running too many releases at the moment, I don't see
>>>>>> my
>>>>>>> opinion as being heavyweight on that subject... Version numbers are
>>>> cheap
>>>>>>> and we've had borked releases before (eg critical IMHO bugs in 2.1.0,
>>>>>> 2.2.0
>>>>>>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
>>>>>> that was
>>>>>>> not released" argument.
>>>>>>>
>>>>>>> In my opinion we need a release status page anyway, eg stating
>> whether
>>>>>>> specific versions are considered stabilising, stable, retired or
>>>> advised
>>>>>>> not to be used... Such a page would remove the need for recycling
>>>> version
>>>>>>> numbers *and* provide benefit to users at the same time.
>>>>>>>
>>>>>>> But I will leave it for others to fight the relative costs of version
>>>>>>> numbers (given the infinite supply) against making sure JIRA release
>>>> notes
>>>>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
>>>> should be
>>>>>>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
>>>>>>> required) are correct and saving the risk that a user checks out an
>>>>>>> unreleased tag and tries to build that from source and then starts
>>>> trying
>>>>>>> to raise bugs against a non-exist any version!
>>>>>>>
>>>>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>>>>>>
>>>>>>>> We need a slight modification of this strategy because the changes
>>>>>> need
>>>>>>> to
>>>>>>>> be pushed somewhere so that people can examine the tag if they want
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;><javascript:;>
>>>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;><javascript:;>
>>>>
>>>>
>>>
>>> --
>>> Sent from my phone
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Sent from my phone
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Stephen Connolly <st...@gmail.com>.
The difference is that you say those versions did not pass QA.
As a user I'd rather know that what I have *unabiguously* passed QA
(whatever that QA process is, and however lax it is) than know the
increasing version numbers. On top of that, if we go increasing, with no
skips, we are actually giving people a false sense of extra QA... By
telling people "go to this page where we list the status of each version"
then they will not be confused at all... Instead they get greater
confidence...
They will see
* some versions we never released a binary for... Those were really bad
* some versions we released a binary for... And then found critical bugs is
* some versions we released a binary for, but its only recent so there
could be regressions our test suite missed
* some versions we reased a binary for, have had no serious issues raised
for the past 6 weeks and are considered stable
* some versions we no longer recommend
As a user such a page gives me much more confidence in the project rather
than our current "every release is a release" lase fair attitude that saw
2.1.0 pushed as the latest for longer than was healthy given the artifact
signing issues. As a user it also gives me more confidence that once I see
a new release transition to stable (say 6 weeks) or recommended (say 3
months) that I am following the project guidelines
I am not saying the version would be missing (the tag would always be
there) but that a binary or source dist would not...
Everyone is entitled to their opinion... previously it was Maven developers
who said no missing version... Iirc you are the first to suggest users
would be confused.... Have we actually asked users which is more confusing?
On Saturday, 14 September 2013, Jason van Zyl wrote:
> I don't agree. I think this would be massively confusing to people if a
> version was missing, or several failed and you went from 3.1.0 to 3.1.3. I
> don't think that would make much sense to most users.
>
> On Sep 14, 2013, at 5:49 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On Saturday, 14 September 2013, Dennis Lundberg wrote:
> >
> >> JIRA is not a big problem. Say for example that the 3.1.1 release was
> >> abandoned due to some problem, you would simply rename the version in
> >> JIRA from 3.1.1 to 3.1.2.
> >
> >
> > Exactly.
> >
> > Not a problem if you ask me... The only one I can think of if the javadoc
> > @since tags and even without skipping versions they can end up at a
> > unreleased version label, plus they are just a >= which will be valid
> anyway
> >
> >
> >>
> >> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de>
> wrote:
> >>> I think it's mainly because the maintenance and housekeeping costs on
> >> the JIRA front and others which use the version nr as reference.
> >>>
> >>>
> >>> Imagine that you would need to move all the JIRA tickets which got
> >> marked as fixed in a certain release as well. Otherwise the release
> notes
> >> would be broken - or would need to get maintained manually.
> >>>
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: Fred Cooke <fr...@gmail.com>
> >>>> To: Maven Developers List <de...@maven.apache.org>
> >>>> Cc:
> >>>> Sent: Saturday, 14 September 2013, 21:51
> >>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >>>>
> >>>> I agree on skipping failed versions! I was avoiding the topic because
> it
> >>>> seemed popular opinion was to re-spin endlessly like a child's
> spinning
> >> top.
> >>>>
> >>>>
> >>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
> >>>> stephen.alan.connolly@gmail.com> wrote:
> >>>>
> >>>>> Why as long as you don't push the tag, there's no big deal. Pushing
> >>>> the tag
> >>>>> is when problems appear... In any case I'd prefer to just skip failed
> >>>>> version numbers... Though I was voted down last time that came up,
> and
> >>>>> given I'm not running too many releases at the moment, I don't see
> >>>> my
> >>>>> opinion as being heavyweight on that subject... Version numbers are
> >> cheap
> >>>>> and we've had borked releases before (eg critical IMHO bugs in 2.1.0,
> >>>> 2.2.0
> >>>>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
> >>>> that was
> >>>>> not released" argument.
> >>>>>
> >>>>> In my opinion we need a release status page anyway, eg stating
> whether
> >>>>> specific versions are considered stabilising, stable, retired or
> >> advised
> >>>>> not to be used... Such a page would remove the need for recycling
> >> version
> >>>>> numbers *and* provide benefit to users at the same time.
> >>>>>
> >>>>> But I will leave it for others to fight the relative costs of version
> >>>>> numbers (given the infinite supply) against making sure JIRA release
> >> notes
> >>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
> >> should be
> >>>>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
> >>>>> required) are correct and saving the risk that a user checks out an
> >>>>> unreleased tag and tries to build that from source and then starts
> >> trying
> >>>>> to raise bugs against a non-exist any version!
> >>>>>
> >>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
> >>>>>
> >>>>>> We need a slight modification of this strategy because the changes
> >>>> need
> >>>>> to
> >>>>>> be pushed somewhere so that people can examine the tag if they want
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;><javascript:;>
> >> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;><javascript:;>
> >>
> >>
> >
> > --
> > Sent from my phone
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>
>
>
>
--
Sent from my phone
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Jason van Zyl <ja...@tesla.io>.
I don't agree. I think this would be massively confusing to people if a version was missing, or several failed and you went from 3.1.0 to 3.1.3. I don't think that would make much sense to most users.
On Sep 14, 2013, at 5:49 PM, Stephen Connolly <st...@gmail.com> wrote:
> On Saturday, 14 September 2013, Dennis Lundberg wrote:
>
>> JIRA is not a big problem. Say for example that the 3.1.1 release was
>> abandoned due to some problem, you would simply rename the version in
>> JIRA from 3.1.1 to 3.1.2.
>
>
> Exactly.
>
> Not a problem if you ask me... The only one I can think of if the javadoc
> @since tags and even without skipping versions they can end up at a
> unreleased version label, plus they are just a >= which will be valid anyway
>
>
>>
>> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de> wrote:
>>> I think it's mainly because the maintenance and housekeeping costs on
>> the JIRA front and others which use the version nr as reference.
>>>
>>>
>>> Imagine that you would need to move all the JIRA tickets which got
>> marked as fixed in a certain release as well. Otherwise the release notes
>> would be broken - or would need to get maintained manually.
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Fred Cooke <fr...@gmail.com>
>>>> To: Maven Developers List <de...@maven.apache.org>
>>>> Cc:
>>>> Sent: Saturday, 14 September 2013, 21:51
>>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>>>
>>>> I agree on skipping failed versions! I was avoiding the topic because it
>>>> seemed popular opinion was to re-spin endlessly like a child's spinning
>> top.
>>>>
>>>>
>>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>
>>>>> Why as long as you don't push the tag, there's no big deal. Pushing
>>>> the tag
>>>>> is when problems appear... In any case I'd prefer to just skip failed
>>>>> version numbers... Though I was voted down last time that came up, and
>>>>> given I'm not running too many releases at the moment, I don't see
>>>> my
>>>>> opinion as being heavyweight on that subject... Version numbers are
>> cheap
>>>>> and we've had borked releases before (eg critical IMHO bugs in 2.1.0,
>>>> 2.2.0
>>>>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
>>>> that was
>>>>> not released" argument.
>>>>>
>>>>> In my opinion we need a release status page anyway, eg stating whether
>>>>> specific versions are considered stabilising, stable, retired or
>> advised
>>>>> not to be used... Such a page would remove the need for recycling
>> version
>>>>> numbers *and* provide benefit to users at the same time.
>>>>>
>>>>> But I will leave it for others to fight the relative costs of version
>>>>> numbers (given the infinite supply) against making sure JIRA release
>> notes
>>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
>> should be
>>>>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
>>>>> required) are correct and saving the risk that a user checks out an
>>>>> unreleased tag and tries to build that from source and then starts
>> trying
>>>>> to raise bugs against a non-exist any version!
>>>>>
>>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>>>>
>>>>>> We need a slight modification of this strategy because the changes
>>>> need
>>>>> to
>>>>>> be pushed somewhere so that people can examine the tag if they want
>>>>> during
>>>>>> the release. I can't keep it on my machine until the vote passes.
>>>>>>
>>>>>> On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de>
>>>> wrote:
>>>>>>
>>>>>>> +1, that's what we also use in DeltaSpike and dozen other
>>>> projects.
>>>>>>> pushChanges=false + localCheckout=true for the win!
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: Arnaud Héritier <ah...@gmail.com>
>>>>>>>> To: Maven Developers List <de...@maven.apache.org>
>>>>>>>> Cc:
>>>>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>>
>>
>
> --
> Sent from my phone
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Stephen Connolly <st...@gmail.com>.
On Saturday, 14 September 2013, Dennis Lundberg wrote:
> JIRA is not a big problem. Say for example that the 3.1.1 release was
> abandoned due to some problem, you would simply rename the version in
> JIRA from 3.1.1 to 3.1.2.
Exactly.
Not a problem if you ask me... The only one I can think of if the javadoc
@since tags and even without skipping versions they can end up at a
unreleased version label, plus they are just a >= which will be valid anyway
>
> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de> wrote:
> > I think it's mainly because the maintenance and housekeeping costs on
> the JIRA front and others which use the version nr as reference.
> >
> >
> > Imagine that you would need to move all the JIRA tickets which got
> marked as fixed in a certain release as well. Otherwise the release notes
> would be broken - or would need to get maintained manually.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> >> From: Fred Cooke <fr...@gmail.com>
> >> To: Maven Developers List <de...@maven.apache.org>
> >> Cc:
> >> Sent: Saturday, 14 September 2013, 21:51
> >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >>
> >> I agree on skipping failed versions! I was avoiding the topic because it
> >> seemed popular opinion was to re-spin endlessly like a child's spinning
> top.
> >>
> >>
> >> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
> >> stephen.alan.connolly@gmail.com> wrote:
> >>
> >>> Why as long as you don't push the tag, there's no big deal. Pushing
> >> the tag
> >>> is when problems appear... In any case I'd prefer to just skip failed
> >>> version numbers... Though I was voted down last time that came up, and
> >>> given I'm not running too many releases at the moment, I don't see
> >> my
> >>> opinion as being heavyweight on that subject... Version numbers are
> cheap
> >>> and we've had borked releases before (eg critical IMHO bugs in 2.1.0,
> >> 2.2.0
> >>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
> >> that was
> >>> not released" argument.
> >>>
> >>> In my opinion we need a release status page anyway, eg stating whether
> >>> specific versions are considered stabilising, stable, retired or
> advised
> >>> not to be used... Such a page would remove the need for recycling
> version
> >>> numbers *and* provide benefit to users at the same time.
> >>>
> >>> But I will leave it for others to fight the relative costs of version
> >>> numbers (given the infinite supply) against making sure JIRA release
> notes
> >>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
> should be
> >>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
> >>> required) are correct and saving the risk that a user checks out an
> >>> unreleased tag and tries to build that from source and then starts
> trying
> >>> to raise bugs against a non-exist any version!
> >>>
> >>> On Saturday, 14 September 2013, Jason van Zyl wrote:
> >>>
> >>> > We need a slight modification of this strategy because the changes
> >> need
> >>> to
> >>> > be pushed somewhere so that people can examine the tag if they want
> >>> during
> >>> > the release. I can't keep it on my machine until the vote passes.
> >>> >
> >>> > On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de>
> >> wrote:
> >>> >
> >>> > > +1, that's what we also use in DeltaSpike and dozen other
> >> projects.
> >>> > > pushChanges=false + localCheckout=true for the win!
> >>> > >
> >>> > > LieGrue,
> >>> > > strub
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > > ----- Original Message -----
> >>> > >> From: Arnaud Héritier <ah...@gmail.com>
> >>> > >> To: Maven Developers List <de...@maven.apache.org>
> >>> > >> Cc:
> >>> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
--
Sent from my phone
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
FFS, Mark. You know better than to argue with me about Git, don't you? :-p
Label in a file system = hard link. Garbage collection (space available) =
no hard links to inodes. Cut the shit man :-p
Nit picking is a BIG understatement :-p
Fred.
On Sat, Sep 14, 2013 at 11:12 PM, Dennis Lundberg <de...@apache.org>wrote:
> JIRA is not a big problem. Say for example that the 3.1.1 release was
> abandoned due to some problem, you would simply rename the version in
> JIRA from 3.1.1 to 3.1.2.
>
> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de> wrote:
> > I think it's mainly because the maintenance and housekeeping costs on
> the JIRA front and others which use the version nr as reference.
> >
> >
> > Imagine that you would need to move all the JIRA tickets which got
> marked as fixed in a certain release as well. Otherwise the release notes
> would be broken - or would need to get maintained manually.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> >> From: Fred Cooke <fr...@gmail.com>
> >> To: Maven Developers List <de...@maven.apache.org>
> >> Cc:
> >> Sent: Saturday, 14 September 2013, 21:51
> >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >>
> >> I agree on skipping failed versions! I was avoiding the topic because it
> >> seemed popular opinion was to re-spin endlessly like a child's spinning
> top.
> >>
> >>
> >> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
> >> stephen.alan.connolly@gmail.com> wrote:
> >>
> >>> Why as long as you don't push the tag, there's no big deal. Pushing
> >> the tag
> >>> is when problems appear... In any case I'd prefer to just skip failed
> >>> version numbers... Though I was voted down last time that came up, and
> >>> given I'm not running too many releases at the moment, I don't see
> >> my
> >>> opinion as being heavyweight on that subject... Version numbers are
> cheap
> >>> and we've had borked releases before (eg critical IMHO bugs in 2.1.0,
> >> 2.2.0
> >>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
> >> that was
> >>> not released" argument.
> >>>
> >>> In my opinion we need a release status page anyway, eg stating whether
> >>> specific versions are considered stabilising, stable, retired or
> advised
> >>> not to be used... Such a page would remove the need for recycling
> version
> >>> numbers *and* provide benefit to users at the same time.
> >>>
> >>> But I will leave it for others to fight the relative costs of version
> >>> numbers (given the infinite supply) against making sure JIRA release
> notes
> >>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
> should be
> >>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
> >>> required) are correct and saving the risk that a user checks out an
> >>> unreleased tag and tries to build that from source and then starts
> trying
> >>> to raise bugs against a non-exist any version!
> >>>
> >>> On Saturday, 14 September 2013, Jason van Zyl wrote:
> >>>
> >>> > We need a slight modification of this strategy because the changes
> >> need
> >>> to
> >>> > be pushed somewhere so that people can examine the tag if they want
> >>> during
> >>> > the release. I can't keep it on my machine until the vote passes.
> >>> >
> >>> > On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de>
> >> wrote:
> >>> >
> >>> > > +1, that's what we also use in DeltaSpike and dozen other
> >> projects.
> >>> > > pushChanges=false + localCheckout=true for the win!
> >>> > >
> >>> > > LieGrue,
> >>> > > strub
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > > ----- Original Message -----
> >>> > >> From: Arnaud Héritier <ah...@gmail.com>
> >>> > >> To: Maven Developers List <de...@maven.apache.org>
> >>> > >> Cc:
> >>> > >> Sent: Saturday, 14 September 2013, 19:45
> >>> > >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >>> > >>
> >>> > >> G ood practice too. I'm using it also at work and we are
> >> doing our
> >>> > >> releases on dedicated branches.
> >>> > >>
> >>> > >> ---------
> >>> > >> Arnaud
> >>> > >>
> >>> > >> Le 14 sept. 2013 à 19:30, Fred Cooke
> >> <fr...@gmail.com> a écrit :
> >>> > >>
> >>> > >>> You're in Git now. You don't *have* to push your
> >> tag and release
> >>> > >> commits up
> >>> > >>> to the public world until AFTER you've checked
> >> they're OK. Or by
> >>> > >> failed
> >>> > >>> release do you mean voted down? They could live on
> >> branches until set
> >>> > in
> >>> > >>> stone, then merge --ff-only into master at that point, if
> >> so.
> >>> > >>>
> >>> > >>>
> >>> > >>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl
> >> <ja...@tesla.io>
> >>> > >> wrote:
> >>> > >>>
> >>> > >>>> When a release fails like this it is annoying to have
> >> to rev back
> >>> the
> >>> > >>>> version of the POM. I'm not sure who flipped the
> >> versions in the
> >>> > >> POM and
> >>> > >>>> while it's a little more visible to see what
> >> you're moving
> >>> > >> toward I prefer
> >>> > >>>> the pattern of:
> >>> > >>>>
> >>> > >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT -->
> >> 3.1.2 -->
> >>> > >> 3.1-SNAPSHOT
> >>> > >>>>
> >>> > >>>> I know this may not be obvious to the casual observer
> >> as they may
> >>> > think
> >>> > >>>> 3.1 is next, but I'm personally fine with that.
> >>> > >>>>
> >>> > >>>> Especially after a failed release because then I
> >> don't have to go
> >>> > >> change
> >>> > >>>> all the POMs (whether rolling back manually, using
> >> the release
> >>> > >> rollback,
> >>> > >>>> the version:set command, or whatever else). It's
> >> much easier to
> >>> > >> just fix
> >>> > >>>> what's necessary and carry on.
> >>> > >>>>
> >>> > >>>> Unless anyone objects I would like to go back this
> >> pattern, what I
> >>> > >>>> previously had, because it's far easier to
> >> manage. Ideally it might
> >>> > >> be nice
> >>> > >>>> if all the tools understood 3.1.z-SNAPSHOT but they
> >> don't an in
> >>> > >> lieu of
> >>> > >>>> that I would prefer not to diddle POMs after a failed
> >> release.
> >>> > >>>>
> >>> > >>>> 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
> >>> >
> >>> > ----------------------------------------------------------
> >>>
> >>>
> >>>
> >>> --
> >>> Sent from my phone
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Dennis Lundberg <de...@apache.org>.
JIRA is not a big problem. Say for example that the 3.1.1 release was
abandoned due to some problem, you would simply rename the version in
JIRA from 3.1.1 to 3.1.2.
On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <st...@yahoo.de> wrote:
> I think it's mainly because the maintenance and housekeeping costs on the JIRA front and others which use the version nr as reference.
>
>
> Imagine that you would need to move all the JIRA tickets which got marked as fixed in a certain release as well. Otherwise the release notes would be broken - or would need to get maintained manually.
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Fred Cooke <fr...@gmail.com>
>> To: Maven Developers List <de...@maven.apache.org>
>> Cc:
>> Sent: Saturday, 14 September 2013, 21:51
>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>
>> I agree on skipping failed versions! I was avoiding the topic because it
>> seemed popular opinion was to re-spin endlessly like a child's spinning top.
>>
>>
>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> Why as long as you don't push the tag, there's no big deal. Pushing
>> the tag
>>> is when problems appear... In any case I'd prefer to just skip failed
>>> version numbers... Though I was voted down last time that came up, and
>>> given I'm not running too many releases at the moment, I don't see
>> my
>>> opinion as being heavyweight on that subject... Version numbers are cheap
>>> and we've had borked releases before (eg critical IMHO bugs in 2.1.0,
>> 2.2.0
>>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
>> that was
>>> not released" argument.
>>>
>>> In my opinion we need a release status page anyway, eg stating whether
>>> specific versions are considered stabilising, stable, retired or advised
>>> not to be used... Such a page would remove the need for recycling version
>>> numbers *and* provide benefit to users at the same time.
>>>
>>> But I will leave it for others to fight the relative costs of version
>>> numbers (given the infinite supply) against making sure JIRA release notes
>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it should be
>>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
>>> required) are correct and saving the risk that a user checks out an
>>> unreleased tag and tries to build that from source and then starts trying
>>> to raise bugs against a non-exist any version!
>>>
>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>>
>>> > We need a slight modification of this strategy because the changes
>> need
>>> to
>>> > be pushed somewhere so that people can examine the tag if they want
>>> during
>>> > the release. I can't keep it on my machine until the vote passes.
>>> >
>>> > On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de>
>> wrote:
>>> >
>>> > > +1, that's what we also use in DeltaSpike and dozen other
>> projects.
>>> > > pushChanges=false + localCheckout=true for the win!
>>> > >
>>> > > LieGrue,
>>> > > strub
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > ----- Original Message -----
>>> > >> From: Arnaud Héritier <ah...@gmail.com>
>>> > >> To: Maven Developers List <de...@maven.apache.org>
>>> > >> Cc:
>>> > >> Sent: Saturday, 14 September 2013, 19:45
>>> > >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>> > >>
>>> > >> G ood practice too. I'm using it also at work and we are
>> doing our
>>> > >> releases on dedicated branches.
>>> > >>
>>> > >> ---------
>>> > >> Arnaud
>>> > >>
>>> > >> Le 14 sept. 2013 à 19:30, Fred Cooke
>> <fr...@gmail.com> a écrit :
>>> > >>
>>> > >>> You're in Git now. You don't *have* to push your
>> tag and release
>>> > >> commits up
>>> > >>> to the public world until AFTER you've checked
>> they're OK. Or by
>>> > >> failed
>>> > >>> release do you mean voted down? They could live on
>> branches until set
>>> > in
>>> > >>> stone, then merge --ff-only into master at that point, if
>> so.
>>> > >>>
>>> > >>>
>>> > >>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl
>> <ja...@tesla.io>
>>> > >> wrote:
>>> > >>>
>>> > >>>> When a release fails like this it is annoying to have
>> to rev back
>>> the
>>> > >>>> version of the POM. I'm not sure who flipped the
>> versions in the
>>> > >> POM and
>>> > >>>> while it's a little more visible to see what
>> you're moving
>>> > >> toward I prefer
>>> > >>>> the pattern of:
>>> > >>>>
>>> > >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT -->
>> 3.1.2 -->
>>> > >> 3.1-SNAPSHOT
>>> > >>>>
>>> > >>>> I know this may not be obvious to the casual observer
>> as they may
>>> > think
>>> > >>>> 3.1 is next, but I'm personally fine with that.
>>> > >>>>
>>> > >>>> Especially after a failed release because then I
>> don't have to go
>>> > >> change
>>> > >>>> all the POMs (whether rolling back manually, using
>> the release
>>> > >> rollback,
>>> > >>>> the version:set command, or whatever else). It's
>> much easier to
>>> > >> just fix
>>> > >>>> what's necessary and carry on.
>>> > >>>>
>>> > >>>> Unless anyone objects I would like to go back this
>> pattern, what I
>>> > >>>> previously had, because it's far easier to
>> manage. Ideally it might
>>> > >> be nice
>>> > >>>> if all the tools understood 3.1.z-SNAPSHOT but they
>> don't an in
>>> > >> lieu of
>>> > >>>> that I would prefer not to diddle POMs after a failed
>> release.
>>> > >>>>
>>> > >>>> 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
>>> >
>>> > ----------------------------------------------------------
>>>
>>>
>>>
>>> --
>>> Sent from my phone
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Mark Struberg <st...@yahoo.de>.
I think it's mainly because the maintenance and housekeeping costs on the JIRA front and others which use the version nr as reference.
Imagine that you would need to move all the JIRA tickets which got marked as fixed in a certain release as well. Otherwise the release notes would be broken - or would need to get maintained manually.
LieGrue,
strub
----- Original Message -----
> From: Fred Cooke <fr...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Saturday, 14 September 2013, 21:51
> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>
> I agree on skipping failed versions! I was avoiding the topic because it
> seemed popular opinion was to re-spin endlessly like a child's spinning top.
>
>
> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> Why as long as you don't push the tag, there's no big deal. Pushing
> the tag
>> is when problems appear... In any case I'd prefer to just skip failed
>> version numbers... Though I was voted down last time that came up, and
>> given I'm not running too many releases at the moment, I don't see
> my
>> opinion as being heavyweight on that subject... Version numbers are cheap
>> and we've had borked releases before (eg critical IMHO bugs in 2.1.0,
> 2.2.0
>> and 3.1.0...) so I don't buy the "what if a user checks out a tag
> that was
>> not released" argument.
>>
>> In my opinion we need a release status page anyway, eg stating whether
>> specific versions are considered stabilising, stable, retired or advised
>> not to be used... Such a page would remove the need for recycling version
>> numbers *and* provide benefit to users at the same time.
>>
>> But I will leave it for others to fight the relative costs of version
>> numbers (given the infinite supply) against making sure JIRA release notes
>> and javadoc @since tags (which is stupid, @since 3.2.3 means it should be
>> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
>> required) are correct and saving the risk that a user checks out an
>> unreleased tag and tries to build that from source and then starts trying
>> to raise bugs against a non-exist any version!
>>
>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>
>> > We need a slight modification of this strategy because the changes
> need
>> to
>> > be pushed somewhere so that people can examine the tag if they want
>> during
>> > the release. I can't keep it on my machine until the vote passes.
>> >
>> > On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de>
> wrote:
>> >
>> > > +1, that's what we also use in DeltaSpike and dozen other
> projects.
>> > > pushChanges=false + localCheckout=true for the win!
>> > >
>> > > LieGrue,
>> > > strub
>> > >
>> > >
>> > >
>> > >
>> > > ----- Original Message -----
>> > >> From: Arnaud Héritier <ah...@gmail.com>
>> > >> To: Maven Developers List <de...@maven.apache.org>
>> > >> Cc:
>> > >> Sent: Saturday, 14 September 2013, 19:45
>> > >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>> > >>
>> > >> G ood practice too. I'm using it also at work and we are
> doing our
>> > >> releases on dedicated branches.
>> > >>
>> > >> ---------
>> > >> Arnaud
>> > >>
>> > >> Le 14 sept. 2013 à 19:30, Fred Cooke
> <fr...@gmail.com> a écrit :
>> > >>
>> > >>> You're in Git now. You don't *have* to push your
> tag and release
>> > >> commits up
>> > >>> to the public world until AFTER you've checked
> they're OK. Or by
>> > >> failed
>> > >>> release do you mean voted down? They could live on
> branches until set
>> > in
>> > >>> stone, then merge --ff-only into master at that point, if
> so.
>> > >>>
>> > >>>
>> > >>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl
> <ja...@tesla.io>
>> > >> wrote:
>> > >>>
>> > >>>> When a release fails like this it is annoying to have
> to rev back
>> the
>> > >>>> version of the POM. I'm not sure who flipped the
> versions in the
>> > >> POM and
>> > >>>> while it's a little more visible to see what
> you're moving
>> > >> toward I prefer
>> > >>>> the pattern of:
>> > >>>>
>> > >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT -->
> 3.1.2 -->
>> > >> 3.1-SNAPSHOT
>> > >>>>
>> > >>>> I know this may not be obvious to the casual observer
> as they may
>> > think
>> > >>>> 3.1 is next, but I'm personally fine with that.
>> > >>>>
>> > >>>> Especially after a failed release because then I
> don't have to go
>> > >> change
>> > >>>> all the POMs (whether rolling back manually, using
> the release
>> > >> rollback,
>> > >>>> the version:set command, or whatever else). It's
> much easier to
>> > >> just fix
>> > >>>> what's necessary and carry on.
>> > >>>>
>> > >>>> Unless anyone objects I would like to go back this
> pattern, what I
>> > >>>> previously had, because it's far easier to
> manage. Ideally it might
>> > >> be nice
>> > >>>> if all the tools understood 3.1.z-SNAPSHOT but they
> don't an in
>> > >> lieu of
>> > >>>> that I would prefer not to diddle POMs after a failed
> release.
>> > >>>>
>> > >>>> 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
>> >
>> > ----------------------------------------------------------
>>
>>
>>
>> --
>> Sent from my phone
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
I agree on skipping failed versions! I was avoiding the topic because it
seemed popular opinion was to re-spin endlessly like a child's spinning top.
On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> Why as long as you don't push the tag, there's no big deal. Pushing the tag
> is when problems appear... In any case I'd prefer to just skip failed
> version numbers... Though I was voted down last time that came up, and
> given I'm not running too many releases at the moment, I don't see my
> opinion as being heavyweight on that subject... Version numbers are cheap
> and we've had borked releases before (eg critical IMHO bugs in 2.1.0, 2.2.0
> and 3.1.0...) so I don't buy the "what if a user checks out a tag that was
> not released" argument.
>
> In my opinion we need a release status page anyway, eg stating whether
> specific versions are considered stabilising, stable, retired or advised
> not to be used... Such a page would remove the need for recycling version
> numbers *and* provide benefit to users at the same time.
>
> But I will leave it for others to fight the relative costs of version
> numbers (given the infinite supply) against making sure JIRA release notes
> and javadoc @since tags (which is stupid, @since 3.2.3 means it should be
> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
> required) are correct and saving the risk that a user checks out an
> unreleased tag and tries to build that from source and then starts trying
> to raise bugs against a non-exist any version!
>
> On Saturday, 14 September 2013, Jason van Zyl wrote:
>
> > We need a slight modification of this strategy because the changes need
> to
> > be pushed somewhere so that people can examine the tag if they want
> during
> > the release. I can't keep it on my machine until the vote passes.
> >
> > On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de> wrote:
> >
> > > +1, that's what we also use in DeltaSpike and dozen other projects.
> > > pushChanges=false + localCheckout=true for the win!
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > >> From: Arnaud Héritier <ah...@gmail.com>
> > >> To: Maven Developers List <de...@maven.apache.org>
> > >> Cc:
> > >> Sent: Saturday, 14 September 2013, 19:45
> > >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> > >>
> > >> G ood practice too. I'm using it also at work and we are doing our
> > >> releases on dedicated branches.
> > >>
> > >> ---------
> > >> Arnaud
> > >>
> > >> Le 14 sept. 2013 à 19:30, Fred Cooke <fr...@gmail.com> a écrit :
> > >>
> > >>> You're in Git now. You don't *have* to push your tag and release
> > >> commits up
> > >>> to the public world until AFTER you've checked they're OK. Or by
> > >> failed
> > >>> release do you mean voted down? They could live on branches until set
> > in
> > >>> stone, then merge --ff-only into master at that point, if so.
> > >>>
> > >>>
> > >>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <ja...@tesla.io>
> > >> wrote:
> > >>>
> > >>>> When a release fails like this it is annoying to have to rev back
> the
> > >>>> version of the POM. I'm not sure who flipped the versions in the
> > >> POM and
> > >>>> while it's a little more visible to see what you're moving
> > >> toward I prefer
> > >>>> the pattern of:
> > >>>>
> > >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 -->
> > >> 3.1-SNAPSHOT
> > >>>>
> > >>>> I know this may not be obvious to the casual observer as they may
> > think
> > >>>> 3.1 is next, but I'm personally fine with that.
> > >>>>
> > >>>> Especially after a failed release because then I don't have to go
> > >> change
> > >>>> all the POMs (whether rolling back manually, using the release
> > >> rollback,
> > >>>> the version:set command, or whatever else). It's much easier to
> > >> just fix
> > >>>> what's necessary and carry on.
> > >>>>
> > >>>> Unless anyone objects I would like to go back this pattern, what I
> > >>>> previously had, because it's far easier to manage. Ideally it might
> > >> be nice
> > >>>> if all the tools understood 3.1.z-SNAPSHOT but they don't an in
> > >> lieu of
> > >>>> that I would prefer not to diddle POMs after a failed release.
> > >>>>
> > >>>> 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
> >
> > ----------------------------------------------------------
>
>
>
> --
> Sent from my phone
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Stephen Connolly <st...@gmail.com>.
Why as long as you don't push the tag, there's no big deal. Pushing the tag
is when problems appear... In any case I'd prefer to just skip failed
version numbers... Though I was voted down last time that came up, and
given I'm not running too many releases at the moment, I don't see my
opinion as being heavyweight on that subject... Version numbers are cheap
and we've had borked releases before (eg critical IMHO bugs in 2.1.0, 2.2.0
and 3.1.0...) so I don't buy the "what if a user checks out a tag that was
not released" argument.
In my opinion we need a release status page anyway, eg stating whether
specific versions are considered stabilising, stable, retired or advised
not to be used... Such a page would remove the need for recycling version
numbers *and* provide benefit to users at the same time.
But I will leave it for others to fight the relative costs of version
numbers (given the infinite supply) against making sure JIRA release notes
and javadoc @since tags (which is stupid, @since 3.2.3 means it should be
there in the 3.3.0 release that 3.2.3 became, so no fix strictly
required) are correct and saving the risk that a user checks out an
unreleased tag and tries to build that from source and then starts trying
to raise bugs against a non-exist any version!
On Saturday, 14 September 2013, Jason van Zyl wrote:
> We need a slight modification of this strategy because the changes need to
> be pushed somewhere so that people can examine the tag if they want during
> the release. I can't keep it on my machine until the vote passes.
>
> On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de> wrote:
>
> > +1, that's what we also use in DeltaSpike and dozen other projects.
> > pushChanges=false + localCheckout=true for the win!
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > ----- Original Message -----
> >> From: Arnaud Héritier <ah...@gmail.com>
> >> To: Maven Developers List <de...@maven.apache.org>
> >> Cc:
> >> Sent: Saturday, 14 September 2013, 19:45
> >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >>
> >> G ood practice too. I'm using it also at work and we are doing our
> >> releases on dedicated branches.
> >>
> >> ---------
> >> Arnaud
> >>
> >> Le 14 sept. 2013 à 19:30, Fred Cooke <fr...@gmail.com> a écrit :
> >>
> >>> You're in Git now. You don't *have* to push your tag and release
> >> commits up
> >>> to the public world until AFTER you've checked they're OK. Or by
> >> failed
> >>> release do you mean voted down? They could live on branches until set
> in
> >>> stone, then merge --ff-only into master at that point, if so.
> >>>
> >>>
> >>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <ja...@tesla.io>
> >> wrote:
> >>>
> >>>> When a release fails like this it is annoying to have to rev back the
> >>>> version of the POM. I'm not sure who flipped the versions in the
> >> POM and
> >>>> while it's a little more visible to see what you're moving
> >> toward I prefer
> >>>> the pattern of:
> >>>>
> >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 -->
> >> 3.1-SNAPSHOT
> >>>>
> >>>> I know this may not be obvious to the casual observer as they may
> think
> >>>> 3.1 is next, but I'm personally fine with that.
> >>>>
> >>>> Especially after a failed release because then I don't have to go
> >> change
> >>>> all the POMs (whether rolling back manually, using the release
> >> rollback,
> >>>> the version:set command, or whatever else). It's much easier to
> >> just fix
> >>>> what's necessary and carry on.
> >>>>
> >>>> Unless anyone objects I would like to go back this pattern, what I
> >>>> previously had, because it's far easier to manage. Ideally it might
> >> be nice
> >>>> if all the tools understood 3.1.z-SNAPSHOT but they don't an in
> >> lieu of
> >>>> that I would prefer not to diddle POMs after a failed release.
> >>>>
> >>>> 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
>
> ----------------------------------------------------------
--
Sent from my phone
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Jason van Zyl <ja...@tesla.io>.
We need a slight modification of this strategy because the changes need to be pushed somewhere so that people can examine the tag if they want during the release. I can't keep it on my machine until the vote passes.
On Sep 14, 2013, at 2:20 PM, Mark Struberg <st...@yahoo.de> wrote:
> +1, that's what we also use in DeltaSpike and dozen other projects.
> pushChanges=false + localCheckout=true for the win!
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Arnaud Héritier <ah...@gmail.com>
>> To: Maven Developers List <de...@maven.apache.org>
>> Cc:
>> Sent: Saturday, 14 September 2013, 19:45
>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>
>> G ood practice too. I'm using it also at work and we are doing our
>> releases on dedicated branches.
>>
>> ---------
>> Arnaud
>>
>> Le 14 sept. 2013 à 19:30, Fred Cooke <fr...@gmail.com> a écrit :
>>
>>> You're in Git now. You don't *have* to push your tag and release
>> commits up
>>> to the public world until AFTER you've checked they're OK. Or by
>> failed
>>> release do you mean voted down? They could live on branches until set in
>>> stone, then merge --ff-only into master at that point, if so.
>>>
>>>
>>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <ja...@tesla.io>
>> wrote:
>>>
>>>> When a release fails like this it is annoying to have to rev back the
>>>> version of the POM. I'm not sure who flipped the versions in the
>> POM and
>>>> while it's a little more visible to see what you're moving
>> toward I prefer
>>>> the pattern of:
>>>>
>>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 -->
>> 3.1-SNAPSHOT
>>>>
>>>> I know this may not be obvious to the casual observer as they may think
>>>> 3.1 is next, but I'm personally fine with that.
>>>>
>>>> Especially after a failed release because then I don't have to go
>> change
>>>> all the POMs (whether rolling back manually, using the release
>> rollback,
>>>> the version:set command, or whatever else). It's much easier to
>> just fix
>>>> what's necessary and carry on.
>>>>
>>>> Unless anyone objects I would like to go back this pattern, what I
>>>> previously had, because it's far easier to manage. Ideally it might
>> be nice
>>>> if all the tools understood 3.1.z-SNAPSHOT but they don't an in
>> lieu of
>>>> that I would prefer not to diddle POMs after a failed release.
>>>>
>>>> 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
---------------------------------------------------------
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Mark Derricutt <ma...@talios.com>.
There was an old JIRA floating around to make that combination the default for git/mercurial and other distributed version control tools.
Not sure what ever happened to that tho. We add that configuration to every project we do with git.
On 15/09/2013, at 6:20 AM, Mark Struberg <st...@yahoo.de> wrote:
> +1, that's what we also use in DeltaSpike and dozen other projects.
> pushChanges=false + localCheckout=true for the win!
-- Mark Derricutt ( mark@talios.com )
— twitter: https://twitter.com/talios
— podcast: http://www.illegalargument.com
— blog: http://www.theoryinpractice.net
— google+: http://gplus.to/talios
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Mark Struberg <st...@yahoo.de>.
+1, that's what we also use in DeltaSpike and dozen other projects.
pushChanges=false + localCheckout=true for the win!
LieGrue,
strub
----- Original Message -----
> From: Arnaud Héritier <ah...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Saturday, 14 September 2013, 19:45
> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>
>G ood practice too. I'm using it also at work and we are doing our
> releases on dedicated branches.
>
> ---------
> Arnaud
>
> Le 14 sept. 2013 à 19:30, Fred Cooke <fr...@gmail.com> a écrit :
>
>> You're in Git now. You don't *have* to push your tag and release
> commits up
>> to the public world until AFTER you've checked they're OK. Or by
> failed
>> release do you mean voted down? They could live on branches until set in
>> stone, then merge --ff-only into master at that point, if so.
>>
>>
>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <ja...@tesla.io>
> wrote:
>>
>>> When a release fails like this it is annoying to have to rev back the
>>> version of the POM. I'm not sure who flipped the versions in the
> POM and
>>> while it's a little more visible to see what you're moving
> toward I prefer
>>> the pattern of:
>>>
>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 -->
> 3.1-SNAPSHOT
>>>
>>> I know this may not be obvious to the casual observer as they may think
>>> 3.1 is next, but I'm personally fine with that.
>>>
>>> Especially after a failed release because then I don't have to go
> change
>>> all the POMs (whether rolling back manually, using the release
> rollback,
>>> the version:set command, or whatever else). It's much easier to
> just fix
>>> what's necessary and carry on.
>>>
>>> Unless anyone objects I would like to go back this pattern, what I
>>> previously had, because it's far easier to manage. Ideally it might
> be nice
>>> if all the tools understood 3.1.z-SNAPSHOT but they don't an in
> lieu of
>>> that I would prefer not to diddle POMs after a failed release.
>>>
>>> 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Arnaud Héritier <ah...@gmail.com>.
Good practice too. I'm using it also at work and we are doing our
releases on dedicated branches.
---------
Arnaud
Le 14 sept. 2013 à 19:30, Fred Cooke <fr...@gmail.com> a écrit :
> You're in Git now. You don't *have* to push your tag and release commits up
> to the public world until AFTER you've checked they're OK. Or by failed
> release do you mean voted down? They could live on branches until set in
> stone, then merge --ff-only into master at that point, if so.
>
>
> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
>> When a release fails like this it is annoying to have to rev back the
>> version of the POM. I'm not sure who flipped the versions in the POM and
>> while it's a little more visible to see what you're moving toward I prefer
>> the pattern of:
>>
>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>>
>> I know this may not be obvious to the casual observer as they may think
>> 3.1 is next, but I'm personally fine with that.
>>
>> Especially after a failed release because then I don't have to go change
>> all the POMs (whether rolling back manually, using the release rollback,
>> the version:set command, or whatever else). It's much easier to just fix
>> what's necessary and carry on.
>>
>> Unless anyone objects I would like to go back this pattern, what I
>> previously had, because it's far easier to manage. Ideally it might be nice
>> if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu of
>> that I would prefer not to diddle POMs after a failed release.
>>
>> 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
You're in Git now. You don't *have* to push your tag and release commits up
to the public world until AFTER you've checked they're OK. Or by failed
release do you mean voted down? They could live on branches until set in
stone, then merge --ff-only into master at that point, if so.
On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <ja...@tesla.io> wrote:
> When a release fails like this it is annoying to have to rev back the
> version of the POM. I'm not sure who flipped the versions in the POM and
> while it's a little more visible to see what you're moving toward I prefer
> the pattern of:
>
> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>
> I know this may not be obvious to the casual observer as they may think
> 3.1 is next, but I'm personally fine with that.
>
> Especially after a failed release because then I don't have to go change
> all the POMs (whether rolling back manually, using the release rollback,
> the version:set command, or whatever else). It's much easier to just fix
> what's necessary and carry on.
>
> Unless anyone objects I would like to go back this pattern, what I
> previously had, because it's far easier to manage. Ideally it might be nice
> if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu of
> that I would prefer not to diddle POMs after a failed release.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>
>
>
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
Fair call.
On Mon, Sep 16, 2013 at 1:39 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> On 16 September 2013 12:26, Fred Cooke <fr...@gmail.com> wrote:
>
> > Version ranges are extremely useful for this case: lib 0.2.4 >> 0.3.0 non
> > inclusive where lib has a guaranteed stable API with only non-breaking
> bug
> > fixes and additions. There are other uses, too. I sincerely hope it's
> never
> > dropped or broken.
> >
> >
> What I want to see, and it would be a change that requires a POM
> specification change, is that version ranges are never provided without a
> "recommended" version.
>
> So I would see something like 1.0.3:[1.0.0,1.1.0),[1.1.1,2.0.0) as meaning
> use 1.0.3 but it should work with anything >= 1.0.0 and < 1.1.0 or >=1.1.1
> but < 2.0.0 (presumably 1.1.0 is known broken)
>
> You could even allow meta-labels when the pom itself is a -SNAPSHOT
> version, e.g.
>
> SNAPSHOT:[1.0.0,1.1.0),[1.1.1,2.0.0)
> LATEST:[1.0.0,1.1.0),[1.1.1,2.0.0)
> STABLE:[1.0.0,1.1.0),[1.1.1,2.0.0)
>
> The first says pick the highest version that is in the range and -SNAPSHOT
> is allowed
> The second says pick the highest release version that is in the range,
> -SNAPSHOT is not allowed
> The third says pick the lowest release version that is in the range,
> -SNAPSHOT is not allowed
>
> When the release plugin runs, it would replace the SNAPSHOT, LATEST or
> STABLE with the most appropriate corresponding release version *at the time
> of release*.
>
> Thus release builds are reproducible always and developers would not need
> to worry about updating poms. Some tooling or CLI options on Maven could
> allow for switching a build from the meta-label in the POM to a specific
> meta-label so that CI builds could probe the extremes easily... and I am
> sure we could provide additional tooling to probe data points within the
> various ranges.
>
> But I would like to see naked ranges dropped from release builds as they
> lead to irreproducible release builds, which is a very bad thing
>
>
> > On Mon, Sep 16, 2013 at 10:09 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > On 16 September 2013 08:20, Jörg Schaible <Joerg.Schaible@scalaris.com
> > > >wrote:
> > >
> > > > Hi Jason,
> > > >
> > > > Jason van Zyl wrote:
> > > >
> > > > > When a release fails like this it is annoying to have to rev back
> the
> > > > > version of the POM. I'm not sure who flipped the versions in the
> POM
> > > and
> > > > > while it's a little more visible to see what you're moving toward I
> > > > prefer
> > > > > the pattern of:
> > > > >
> > > > > 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
> > > > >
> > > > > I know this may not be obvious to the casual observer as they may
> > think
> > > > > 3.1 is next, but I'm personally fine with that.
> > > >
> > > > That's quite funny, because we did this years ago when we started
> using
> > > M2
> > > > and then we were told here in the list it is an anti-pattern, because
> > > 3.1-
> > > > SNAPSHOT is always minor for the dependency resolution than any 3.1.x
> > > > release.
> > > >
> > > >
> > > That was before it was decided that version ranges were a bad plan. If
> we
> > > were using version ranges then this would indeed be crapulent
> > >
> > >
> > > > - Jörg
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Stephen Connolly <st...@gmail.com>.
On 16 September 2013 12:26, Fred Cooke <fr...@gmail.com> wrote:
> Version ranges are extremely useful for this case: lib 0.2.4 >> 0.3.0 non
> inclusive where lib has a guaranteed stable API with only non-breaking bug
> fixes and additions. There are other uses, too. I sincerely hope it's never
> dropped or broken.
>
>
What I want to see, and it would be a change that requires a POM
specification change, is that version ranges are never provided without a
"recommended" version.
So I would see something like 1.0.3:[1.0.0,1.1.0),[1.1.1,2.0.0) as meaning
use 1.0.3 but it should work with anything >= 1.0.0 and < 1.1.0 or >=1.1.1
but < 2.0.0 (presumably 1.1.0 is known broken)
You could even allow meta-labels when the pom itself is a -SNAPSHOT
version, e.g.
SNAPSHOT:[1.0.0,1.1.0),[1.1.1,2.0.0)
LATEST:[1.0.0,1.1.0),[1.1.1,2.0.0)
STABLE:[1.0.0,1.1.0),[1.1.1,2.0.0)
The first says pick the highest version that is in the range and -SNAPSHOT
is allowed
The second says pick the highest release version that is in the range,
-SNAPSHOT is not allowed
The third says pick the lowest release version that is in the range,
-SNAPSHOT is not allowed
When the release plugin runs, it would replace the SNAPSHOT, LATEST or
STABLE with the most appropriate corresponding release version *at the time
of release*.
Thus release builds are reproducible always and developers would not need
to worry about updating poms. Some tooling or CLI options on Maven could
allow for switching a build from the meta-label in the POM to a specific
meta-label so that CI builds could probe the extremes easily... and I am
sure we could provide additional tooling to probe data points within the
various ranges.
But I would like to see naked ranges dropped from release builds as they
lead to irreproducible release builds, which is a very bad thing
> On Mon, Sep 16, 2013 at 10:09 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On 16 September 2013 08:20, Jörg Schaible <Joerg.Schaible@scalaris.com
> > >wrote:
> >
> > > Hi Jason,
> > >
> > > Jason van Zyl wrote:
> > >
> > > > When a release fails like this it is annoying to have to rev back the
> > > > version of the POM. I'm not sure who flipped the versions in the POM
> > and
> > > > while it's a little more visible to see what you're moving toward I
> > > prefer
> > > > the pattern of:
> > > >
> > > > 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
> > > >
> > > > I know this may not be obvious to the casual observer as they may
> think
> > > > 3.1 is next, but I'm personally fine with that.
> > >
> > > That's quite funny, because we did this years ago when we started using
> > M2
> > > and then we were told here in the list it is an anti-pattern, because
> > 3.1-
> > > SNAPSHOT is always minor for the dependency resolution than any 3.1.x
> > > release.
> > >
> > >
> > That was before it was decided that version ranges were a bad plan. If we
> > were using version ranges then this would indeed be crapulent
> >
> >
> > > - Jörg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Fred Cooke <fr...@gmail.com>.
Version ranges are extremely useful for this case: lib 0.2.4 >> 0.3.0 non
inclusive where lib has a guaranteed stable API with only non-breaking bug
fixes and additions. There are other uses, too. I sincerely hope it's never
dropped or broken.
On Mon, Sep 16, 2013 at 10:09 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> On 16 September 2013 08:20, Jörg Schaible <Joerg.Schaible@scalaris.com
> >wrote:
>
> > Hi Jason,
> >
> > Jason van Zyl wrote:
> >
> > > When a release fails like this it is annoying to have to rev back the
> > > version of the POM. I'm not sure who flipped the versions in the POM
> and
> > > while it's a little more visible to see what you're moving toward I
> > prefer
> > > the pattern of:
> > >
> > > 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
> > >
> > > I know this may not be obvious to the casual observer as they may think
> > > 3.1 is next, but I'm personally fine with that.
> >
> > That's quite funny, because we did this years ago when we started using
> M2
> > and then we were told here in the list it is an anti-pattern, because
> 3.1-
> > SNAPSHOT is always minor for the dependency resolution than any 3.1.x
> > release.
> >
> >
> That was before it was decided that version ranges were a bad plan. If we
> were using version ranges then this would indeed be crapulent
>
>
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Stephen Connolly <st...@gmail.com>.
On 16 September 2013 08:20, Jörg Schaible <Jo...@scalaris.com>wrote:
> Hi Jason,
>
> Jason van Zyl wrote:
>
> > When a release fails like this it is annoying to have to rev back the
> > version of the POM. I'm not sure who flipped the versions in the POM and
> > while it's a little more visible to see what you're moving toward I
> prefer
> > the pattern of:
> >
> > 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
> >
> > I know this may not be obvious to the casual observer as they may think
> > 3.1 is next, but I'm personally fine with that.
>
> That's quite funny, because we did this years ago when we started using M2
> and then we were told here in the list it is an anti-pattern, because 3.1-
> SNAPSHOT is always minor for the dependency resolution than any 3.1.x
> release.
>
>
That was before it was decided that version ranges were a bad plan. If we
were using version ranges then this would indeed be crapulent
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Jason,
Jason van Zyl wrote:
> When a release fails like this it is annoying to have to rev back the
> version of the POM. I'm not sure who flipped the versions in the POM and
> while it's a little more visible to see what you're moving toward I prefer
> the pattern of:
>
> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>
> I know this may not be obvious to the casual observer as they may think
> 3.1 is next, but I'm personally fine with that.
That's quite funny, because we did this years ago when we started using M2
and then we were told here in the list it is an anti-pattern, because 3.1-
SNAPSHOT is always minor for the dependency resolution than any 3.1.x
release.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Jason van Zyl <ja...@tesla.io>.
Let me try the ITs quickly and make sure it actually works. If so, I agree with you.
On Sep 14, 2013, at 5:08 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> I prefer this 3.1.x-SNAPSHOT value: the intent is more clear
>
> Regards,
>
> Hervé
>
> Le samedi 14 septembre 2013 19:42:23 Arnaud Héritier a écrit :
>> No problem for me. At work I'm also applying this rule but we use
>> 3.1.x-SNAPSHOT. I didn't notice issues with this
>>
>> Cheers.
>>
>> ---------
>> Arnaud
>>
>> Le 14 sept. 2013 à 19:25, Jason van Zyl <ja...@tesla.io> a écrit :
>>> When a release fails like this it is annoying to have to rev back the
>>> version of the POM. I'm not sure who flipped the versions in the POM and
>>> while it's a little more visible to see what you're moving toward I
>>> prefer the pattern of:
>>>
>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>>>
>>> I know this may not be obvious to the casual observer as they may think
>>> 3.1 is next, but I'm personally fine with that.
>>>
>>> Especially after a failed release because then I don't have to go change
>>> all the POMs (whether rolling back manually, using the release rollback,
>>> the version:set command, or whatever else). It's much easier to just fix
>>> what's necessary and carry on.
>>>
>>> Unless anyone objects I would like to go back this pattern, what I
>>> previously had, because it's far easier to manage. Ideally it might be
>>> nice if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu
>>> of that I would prefer not to diddle POMs after a failed release.
>>>
>>> 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
---------------------------------------------------------
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Jason van Zyl <ja...@tesla.io>.
As I suspected the ITs don't like it. So 3.1-SNAPSHOT it is.
On Sep 14, 2013, at 5:08 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> I prefer this 3.1.x-SNAPSHOT value: the intent is more clear
>
> Regards,
>
> Hervé
>
> Le samedi 14 septembre 2013 19:42:23 Arnaud Héritier a écrit :
>> No problem for me. At work I'm also applying this rule but we use
>> 3.1.x-SNAPSHOT. I didn't notice issues with this
>>
>> Cheers.
>>
>> ---------
>> Arnaud
>>
>> Le 14 sept. 2013 à 19:25, Jason van Zyl <ja...@tesla.io> a écrit :
>>> When a release fails like this it is annoying to have to rev back the
>>> version of the POM. I'm not sure who flipped the versions in the POM and
>>> while it's a little more visible to see what you're moving toward I
>>> prefer the pattern of:
>>>
>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>>>
>>> I know this may not be obvious to the casual observer as they may think
>>> 3.1 is next, but I'm personally fine with that.
>>>
>>> Especially after a failed release because then I don't have to go change
>>> all the POMs (whether rolling back manually, using the release rollback,
>>> the version:set command, or whatever else). It's much easier to just fix
>>> what's necessary and carry on.
>>>
>>> Unless anyone objects I would like to go back this pattern, what I
>>> previously had, because it's far easier to manage. Ideally it might be
>>> nice if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu
>>> of that I would prefer not to diddle POMs after a failed release.
>>>
>>> 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
---------------------------------------------------------
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Hervé BOUTEMY <he...@free.fr>.
I prefer this 3.1.x-SNAPSHOT value: the intent is more clear
Regards,
Hervé
Le samedi 14 septembre 2013 19:42:23 Arnaud Héritier a écrit :
> No problem for me. At work I'm also applying this rule but we use
> 3.1.x-SNAPSHOT. I didn't notice issues with this
>
> Cheers.
>
> ---------
> Arnaud
>
> Le 14 sept. 2013 à 19:25, Jason van Zyl <ja...@tesla.io> a écrit :
> > When a release fails like this it is annoying to have to rev back the
> > version of the POM. I'm not sure who flipped the versions in the POM and
> > while it's a little more visible to see what you're moving toward I
> > prefer the pattern of:
> >
> > 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
> >
> > I know this may not be obvious to the casual observer as they may think
> > 3.1 is next, but I'm personally fine with that.
> >
> > Especially after a failed release because then I don't have to go change
> > all the POMs (whether rolling back manually, using the release rollback,
> > the version:set command, or whatever else). It's much easier to just fix
> > what's necessary and carry on.
> >
> > Unless anyone objects I would like to go back this pattern, what I
> > previously had, because it's far easier to manage. Ideally it might be
> > nice if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu
> > of that I would prefer not to diddle POMs after a failed release.
> >
> > 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Arnaud Héritier <ah...@gmail.com>.
No problem for me. At work I'm also applying this rule but we use
3.1.x-SNAPSHOT. I didn't notice issues with this
Cheers.
---------
Arnaud
Le 14 sept. 2013 à 19:25, Jason van Zyl <ja...@tesla.io> a écrit :
> When a release fails like this it is annoying to have to rev back the version of the POM. I'm not sure who flipped the versions in the POM and while it's a little more visible to see what you're moving toward I prefer the pattern of:
>
> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>
> I know this may not be obvious to the casual observer as they may think 3.1 is next, but I'm personally fine with that.
>
> Especially after a failed release because then I don't have to go change all the POMs (whether rolling back manually, using the release rollback, the version:set command, or whatever else). It's much easier to just fix what's necessary and carry on.
>
> Unless anyone objects I would like to go back this pattern, what I previously had, because it's far easier to manage. Ideally it might be nice if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu of that I would prefer not to diddle POMs after a failed release.
>
> 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Hervé BOUTEMY <he...@free.fr>.
true, having this version during development does not permit core its range as
usual: an IT for a minor version will be run only at release time, but not
before and after
that's a major issue, IMHO
Regards,
Hervé
Le vendredi 4 octobre 2013 07:18:50 Igor Fedorenko a écrit :
> Practical question. What should be supported maven version range for new
> ITs introduced during 3.1.2 development, [3.1,)? This means we'd need to
> tag ITs, right? Otherwise it wouldn't be possible to successfully rerun
> ITs for 3.1 and 3.1.1, unless I am mistaken.
>
> --
> Regards,
> Igor
>
> On 2013-09-14 1:24 PM, Jason van Zyl wrote:
> > When a release fails like this it is annoying to have to rev back the
> > version of the POM. I'm not sure who flipped the versions in the POM
> > and while it's a little more visible to see what you're moving toward
> > I prefer the pattern of:
> >
> > 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
> >
> > I know this may not be obvious to the casual observer as they may
> > think 3.1 is next, but I'm personally fine with that.
> >
> > Especially after a failed release because then I don't have to go
> > change all the POMs (whether rolling back manually, using the release
> > rollback, the version:set command, or whatever else). It's much
> > easier to just fix what's necessary and carry on.
> >
> > Unless anyone objects I would like to go back this pattern, what I
> > previously had, because it's far easier to manage. Ideally it might
> > be nice if all the tools understood 3.1.z-SNAPSHOT but they don't an
> > in lieu of that I would prefer not to diddle POMs after a failed
> > release.
> >
> > 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Robert Scholte <rf...@apache.org>.
Good catch!
Op Fri, 04 Oct 2013 13:18:50 +0200 schreef Igor Fedorenko
<ig...@ifedorenko.com>:
> Practical question. What should be supported maven version range for new
> ITs introduced during 3.1.2 development, [3.1,)? This means we'd need to
> tag ITs, right? Otherwise it wouldn't be possible to successfully rerun
> ITs for 3.1 and 3.1.1, unless I am mistaken.
>
> --
> Regards,
> Igor
>
> On 2013-09-14 1:24 PM, Jason van Zyl wrote:
>> When a release fails like this it is annoying to have to rev back the
>> version of the POM. I'm not sure who flipped the versions in the POM
>> and while it's a little more visible to see what you're moving toward
>> I prefer the pattern of:
>>
>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>>
>> I know this may not be obvious to the casual observer as they may
>> think 3.1 is next, but I'm personally fine with that.
>>
>> Especially after a failed release because then I don't have to go
>> change all the POMs (whether rolling back manually, using the release
>> rollback, the version:set command, or whatever else). It's much
>> easier to just fix what's necessary and carry on.
>>
>> Unless anyone objects I would like to go back this pattern, what I
>> previously had, because it's far easier to manage. Ideally it might
>> be nice if all the tools understood 3.1.z-SNAPSHOT but they don't an
>> in lieu of that I would prefer not to diddle POMs after a failed
>> release.
>>
>> 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Jason van Zyl <ja...@tesla.io>.
Good point. I did some experiments with the version:set plugin and I can live with the rollback using that. So I reset the poms to 3.1.2-SNAPSHOT. Problem solved.
On Oct 4, 2013, at 7:18 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> Practical question. What should be supported maven version range for new
> ITs introduced during 3.1.2 development, [3.1,)? This means we'd need to
> tag ITs, right? Otherwise it wouldn't be possible to successfully rerun
> ITs for 3.1 and 3.1.1, unless I am mistaken.
>
> --
> Regards,
> Igor
>
> On 2013-09-14 1:24 PM, Jason van Zyl wrote:
>> When a release fails like this it is annoying to have to rev back the
>> version of the POM. I'm not sure who flipped the versions in the POM
>> and while it's a little more visible to see what you're moving toward
>> I prefer the pattern of:
>>
>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>>
>> I know this may not be obvious to the casual observer as they may
>> think 3.1 is next, but I'm personally fine with that.
>>
>> Especially after a failed release because then I don't have to go
>> change all the POMs (whether rolling back manually, using the release
>> rollback, the version:set command, or whatever else). It's much
>> easier to just fix what's necessary and carry on.
>>
>> Unless anyone objects I would like to go back this pattern, what I
>> previously had, because it's far easier to manage. Ideally it might
>> be nice if all the tools understood 3.1.z-SNAPSHOT but they don't an
>> in lieu of that I would prefer not to diddle POMs after a failed
>> release.
>>
>> 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
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
Practical question. What should be supported maven version range for new
ITs introduced during 3.1.2 development, [3.1,)? This means we'd need to
tag ITs, right? Otherwise it wouldn't be possible to successfully rerun
ITs for 3.1 and 3.1.1, unless I am mistaken.
--
Regards,
Igor
On 2013-09-14 1:24 PM, Jason van Zyl wrote:
> When a release fails like this it is annoying to have to rev back the
> version of the POM. I'm not sure who flipped the versions in the POM
> and while it's a little more visible to see what you're moving toward
> I prefer the pattern of:
>
> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>
> I know this may not be obvious to the casual observer as they may
> think 3.1 is next, but I'm personally fine with that.
>
> Especially after a failed release because then I don't have to go
> change all the POMs (whether rolling back manually, using the release
> rollback, the version:set command, or whatever else). It's much
> easier to just fix what's necessary and carry on.
>
> Unless anyone objects I would like to go back this pattern, what I
> previously had, because it's far easier to manage. Ideally it might
> be nice if all the tools understood 3.1.z-SNAPSHOT but they don't an
> in lieu of that I would prefer not to diddle POMs after a failed
> release.
>
> 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: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Jason van Zyl <ja...@tesla.io>.
On Sep 14, 2013, at 4:00 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>
> On Sep 14, 2013, at 1:24 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
>> When a release fails like this it is annoying to have to rev back the version of the POM. I'm not sure who flipped the versions in the POM and while it's a little more visible to see what you're moving toward I prefer the pattern of:
>>
>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>>
>> I know this may not be obvious to the casual observer as they may think 3.1 is next, but I'm personally fine with that.
>>
>> Especially after a failed release because then I don't have to go change all the POMs (whether rolling back manually, using the release rollback, the version:set command, or whatever else). It's much easier to just fix what's necessary and carry on.
>
>
> You don't have to go back and reset the poms. Just re-run the maven-release-plugin and when it asks for the release version, type in 3.1.1 instead of defaulting to 3.1.2.
>
Technically, yes I can do that but I think it look odd to go from 3.1.2-SNAPSHOT to 3.1.1. I've already reset them here locally while integrating other fixes. I was pleasantly surprised using version:set which didn't rewrite the POMs but just really did just target the version change. It was painless using version:set.
>
> Dan
>
>
>
>> Unless anyone objects I would like to go back this pattern, what I previously had, because it's far easier to manage. Ideally it might be nice if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu of that I would prefer not to diddle POMs after a failed release.
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Daniel Kulp <dk...@apache.org>.
On Sep 14, 2013, at 1:24 PM, Jason van Zyl <ja...@tesla.io> wrote:
> When a release fails like this it is annoying to have to rev back the version of the POM. I'm not sure who flipped the versions in the POM and while it's a little more visible to see what you're moving toward I prefer the pattern of:
>
> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>
> I know this may not be obvious to the casual observer as they may think 3.1 is next, but I'm personally fine with that.
>
> Especially after a failed release because then I don't have to go change all the POMs (whether rolling back manually, using the release rollback, the version:set command, or whatever else). It's much easier to just fix what's necessary and carry on.
You don't have to go back and reset the poms. Just re-run the maven-release-plugin and when it asks for the release version, type in 3.1.1 instead of defaulting to 3.1.2.
Dan
> Unless anyone objects I would like to go back this pattern, what I previously had, because it's far easier to manage. Ideally it might be nice if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu of that I would prefer not to diddle POMs after a failed release.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>
>
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Posted by Chris Graham <ch...@gmail.com>.
On Sun, Sep 15, 2013 at 3:24 AM, Jason van Zyl <ja...@tesla.io> wrote:
> When a release fails like this it is annoying to have to rev back the
> version of the POM. I'm not sure who flipped the versions in the POM and
> while it's a little more visible to see what you're moving toward I prefer
> the pattern of:
>
> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>
> I know this may not be obvious to the casual observer as they may think
> 3.1 is next, but I'm personally fine with that.
>
>
So, what you've done is to change the meaning of SNAPSHOT.
Why would you not stick with the far more clearly understood:
3.1.1-SNAPSHOT -> 3.1.1 -> 3.1.2-SNAPSHOT -> 3.1.2 etc
If the IT's have issues, then there is clearly something wrong with them,
and they should be fixed.
Did the IT's fail in a similar manner for 3.0.x ?
-Chris