maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Cooke <fred.co...@gmail.com>
Subject Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
Date Sun, 15 Sep 2013 11:30:44 GMT
Exactly! :-)


On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> But you asked the wrong jump then.
>
> It would be 3.0.5 to 4.0.4... There's no way we'd skip 4.0.x to go to 4.1.x
> if we have not had a 4.0.x released at all.
>
> My point is patch version people are perfectly fine with skips.... Minor
> version skips would be bad, but there is zero need for them.
>
> On Sunday, 15 September 2013, Robert Scholte wrote:
>
> > That someone might have been me.
> > I did an internal poll to ask if people would understand if Maven would
> > jump from 3.0.5 to 4.1.3.
> > None of them did, they all wondered what happened to the missing
> versions.
> > Sure they understand that 4.1.3 is newer than 3.0.5, these aren't morons.
> >
> > One major difference is that Maven can't update itself to the latest
> > version. If that would be the case, then versions are only interesting to
> > reproduce issues and people often wouldn't see/matter the version.
> >
> > *If* we would allow gaps, we should also introduce LTS releases.
> >
> > For now, I'd prefer reusing versions and no gaps. I don't mind deleting
> > tags, otherwise I'd prefer the usage of RCx during votes.
> >
> > Robert
> >
> > Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke <
> > fred.cooke@gmail.com>:
> >
> >  Last time someone asked this I went straight to central and found two
> > examples. There are plenty out there. I'm not doing it again, you're more
> > than capable. Also note, it's not much different to go from 3.1.2 to
> 3.1.4
> > than it is from 3.1.5 to 3.2.0; you still miss out versions, an infinite
> > number of them, in fact.
> >
> > Preferring not to have gaps is a choice and one I was aware you lot would
> > make. That's why I didn't bring it up in the first place despite
> preferring
> > to just straight miss them. Or just straight publish all releases (as is
> > normal mvn practice since forever) and direct users to the ones that
> > work... I *think* this is what Stephen is trying to say, but if I'm
> honest
> > I missed out a lot of what he wrote. Forgive me, it's 2am here.
> >
> >
> > On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl <jason@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.cooke@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.connolly@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?
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> Sent from my phone
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message