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 <rfscho...@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.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.connolly@gmail.**com <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? >>> >> >>> >> 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 <stephen.alan.conno...@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 <strub...@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 <fred.co...@gmail.com> >>> >>>>>>> To: Maven Developers List <dev@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<stephen.alan.conno...@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<dev-unsubscr...@maven.apache.org> >>> >> <javascript:;><javascript:;> >>> >>>>> For additional commands, e-mail: dev-h...@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<dev-unsubscr...@maven.apache.org> > For additional commands, e-mail: dev-h...@maven.apache.org > >
