On Sep 14, 2013, at 7:34 PM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote:
> The difference is that you say those versions did not pass QA. > I don't think that will alleviate the confusion, and trying to explain that will unlikely reach our audience and they will just be confused. > 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... I think this is a fictional construction and is not what anyone has ever done with versions traditionally. In products or open source projects there are usually no gaps in the versions that are released. At least not in the marketing versions. If we had a stream of builds versioned by sha1 when there was success you give a version that is in sequence. > 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... I think that's conjecture and not my experience at all. They will not go to a page, they will see a gap and wonder if they missed something. > > 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? > Sure, we can ask them. I don't think users are interested in what happens internally and pay attention when releases actually happen. I don't think we're going to announce failed releases and so there. Do you know of any other projects that skip public versions on failed attempted releases? I don't. > 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 ---------------------------------------------------------
