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? >> >> 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.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.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-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 ---------------------------------------------------------
