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" <denn...@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 <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 > >
