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 <seb...@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 > <stephen.alan.conno...@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 <fred.co...@gmail.com> wrote: > > > >> Exactly! :-) > >> > >> > >> On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly < > >> stephen.alan.conno...@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.co...@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 <fred.co...@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.conno...@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-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >>> -- > >>> Sent from my phone > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
