maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baptiste Mathus>
Subject Re: Releases, Continuous Delivery and the Future
Date Fri, 02 Jan 2015 09:31:52 GMT
Well, I for one find the x.y.z-nn somehow unusual. I'd prefer something
simple like x.y.z and I don't give a f*ck if some numbers are skipped.

+1 with Stephen: I've never seen someone complain about missing versions
neither on ML nor IRL. Sure, I suppose people might wonder where the 4.x
went if the next mvn version was to be 5.0, but apart (and even though)
from the major version, I don't see any developer ever complaining about

Just then let's indeed have a changelog somewhere just for reference that
confirms that the was skipped and never released.
But I'm sure few people will have a look at it and it won't be a concern.

IMO, there are in fact 3 main cases:

1) people stuck with a corp version won't ever deal with that issue and use
what's provided
2) people wanting the latest version, will just go on the website on
download the first link seemingly being the latest one
3) people wanting to do a careful upgrade (certainly most often for the 1/
group, think build/release engineering team) would just carefully read the
release notes to see what bump is safe to do (this is typically what we do
for Jenkins for example)

My 2 cents.

2014-12-28 22:00 GMT+01:00 Brian E. Fox <>:

> > On Dec 14, 2014, at 8:29 PM, Jason van Zyl <> wrote:
> >
> > What we want is a form of continuous delivery where a version like 3.2.4
> is the version that we call it to the outside world (some refer to it as
> the marketing version) and the qualifier changes from build to build so we
> have:
> >
> > 3.2.4-qualifier
> >
> > And for simplicity's sake let's just say the qualifier is a build number
> so we end up with:
> >
> > 3.2.4-01
> > 3.2.4-02
> > ...
> > 3.2.4-NN
> +1
> This really the only viable scheme I've seen used over the years. It's how
> we do it at Sonatype and it's never been an issue that the public version
> is shown with some -build number.
> We will want to ensure that only one release version gets published though
> to reduce confusion. Since everything is staged, this should happen
> normally.
> For plugins, which are commonly referred to by users in their poms, this
> might turn out to be a problem as it increases the maintenance load but I
> think we start trying it and if there is an issue we go to an alternate
> approach.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> --
> Baptiste <Batmat> MATHUS -
> Sauvez un arbre,
> Mangez un castor !
> nbsp;! <>

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