maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: [VOTE] Should we respin CANCELLED releases with the same version number?
Date Thu, 30 May 2013 20:38:13 GMT
This discussion about respins is really strange to me. I've been
cutting releases, with Maven, at Apache, for years now. And all of
them have reused version numbers for respins. And all of them have
carefully used staging technology (old: directories, new: Nexus) to
ensure that artifacts don't escape to the wild until they pass the

The reason for this is simple: it's burned into Maven that the version
number is frozen when you run the release plugin. People complain
about all this all the time; they have an expectation that they can
have an 'RC' version number until that are absolutely, positively,
sure the release is gold, and then change. But Maven won't do that.

Further, projects don't like to 'burn' or skip version numbers just
because of pre-release, internal, mishaps.

Is this discussion, which I haven't followed carefully, I apologize,
special to the main Maven package, as opposed to plugins that we just
release with the release plugin?

To me, anything labelled 'alpha' is _just a test version for the very
brave_. I am particularly not impressed with an immutability argument
for such.

I suppose that the zen side is this: we would hope to do enough
testing on alphas and betas that we could never possible need to
respin a real release. And if people feel strongly enough that we need
to never, ever, even come close to creating two things called '3.1.0'
(e.g.), then we'll have to 'burn' 3.1.0 and skip to 3.1.1 if there's a

What _really_ appeals to me is the even-odd convention from the httpd:
no 'alphas' or 'betas' -- odd numbers are 'at your own risk', even
numbers are 'supported releases'.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message