Json, the JDK7 just went from 25 to 40 for me and I do not mind :-)
Regards Mirko -- Sent from my mobile On Sep 15, 2013 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 > --------------------------------------------------------- > > > > > > > >
