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 <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 > --------------------------------------------------------- > > > > > > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
