If people really don't want to end up skipping numbers, and also people
also don't want to recreate tags, there are solutions.
For example, Lucene recognizes that serious testing of snapshots just never
happens. So, the release manager starts by doing the full release process
for X.Y.Z-RC1. And puts it _up for a vote_. If if it fails, everyone fixes
what's wrong, and the RM tries again with RC2. And repeats, as necessary.
Once some RCn has gets voted OK, it is left out there for the larger
community to poke at a bit, and then the RM makes one more package, for
X.Y.Z, and puts _that_ up for a vote.
The result is that non-RC releases just about never fail, because the
community is diligent about testing the RC releases, and because the fully
voted status of RC releases makes them distributable to a broader
collection of potential testers.
This is just one approach. There's also the even-odd numbering scheme
(httpd, e.g., I think), where some release numbers are documented to just
solicit testing, and others are meant for serious use. Presumably, those
medical establishments are capable of understanding simple patterns. (And I
doubt the applicability of that whole issue to a development tool.)
I'm not advocating here, just offering options.
On Sat, Dec 13, 2014 at 7:28 PM, Jeff Jensen <
jeffjen...@upstairstechnology.com> wrote:
> While I agree with your assessment Paul, the problem with upgrading
> non-sequential release numbers that I encounter with some of my customers
> (the larger organizations or ones with regulated products [think medical])
> is it usually causes some confusion ("we're on version n.2 and I see n.8
> but nothing in between, anyone know what happened? Is this a large jump -
> will we have problems?") and extra work (digging into it multiple times by
> multiple people as each team approaches upgrading tools). The larger the
> gap, the more hassle it may cause for them.
>
> In a build pipeline, I'm very happy to burn through release numbers.
>
> In the Maven release case, since it was never released (only staged for
> review before release), I don't consider it a problem to re-stage/respin
> with the same number. And my favorite perspective to evaluate from is my
> customer's, and some of them would appreciate no version gaps!
>
>
> On Sat, Dec 13, 2014 at 4:46 PM, Paul Benedict <pbened...@apache.org>
> wrote:
> >
> > I can see your point. However, I don't think it's all that unusual for
> > people to see skipped versions during upgrading anymore. For example,
> when
> > a security issue is found in a GA product, the affected version is
> > instantly pulled from distribution sites and a new version is published.
> > Whether a bum internal build or retroactively taking GA from a release,
> if
> > you aren't upgrading frequently, I think skipping versions is not
> shocking.
> > That's my experience anyway. I see you have a different experience but
> glad
> > you shared it.
> >
> >
> > Cheers,
> > Paul
> >
> > On Sat, Dec 13, 2014 at 4:32 PM, Jason van Zyl <ja...@takari.io> wrote:
> > >
> > > Sure, I never wanted to do it which is why I forgot and will likely
> > > continue to forget so I'll change the docs because I always have to
> look
> > at
> > > them to figure out how to publish the site. I still think it's a
> > > inconsistent practice for the few it would inconvenience in a minor
> way.
> > >
> > > On Dec 13, 2014, at 5:27 PM, Paul Benedict <pbened...@apache.org>
> wrote:
> > >
> > > > When the 3.2.0 build had a regression, we jumped to 3.2.1:
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3cdf2f7f9e-9334-43d9-aa01-03733604b...@takari.io%3E
> > > >
> > > > Sorry I didn't provide this thread up front. It took a while to find
> > it.
> > > > However, I am pretty sure we did this again with 3.2.3, but I could
> be
> > > > wrong on that fact -- I just remember we did this twice so far.
> > > >
> > > >
> > > > Cheers,
> > > > Paul
> > > >
> > > > On Sat, Dec 13, 2014 at 4:24 PM, Jason van Zyl <ja...@takari.io>
> > wrote:
> > > >>
> > > >> I don't because it's inconsistent for external users who will be
> > > confused
> > > >> about where a release has gone. To date I have never skipped
> versions,
> > > for
> > > >> consistency I don't want to start now. I consider the staged
> releases
> > > not
> > > >> contributing to the public version pool.
> > > >>
> > > >> For your case I think you're probably the only person in the world
> who
> > > >> integrates a staged release of Maven. For normal testers, running
> > Maven
> > > >> 3.2.4 doesn't download Maven 3.2.4 related binaries in your local
> > repo.
> > > >>
> > > >> But even if you weren't the only person is it that hard to cleanup
> the
> > > >> punched release locally? I see the reuse of versions as being
> > > >> problematically negligible while the confusion for users being high.
> > > >>
> > > >> On Dec 13, 2014, at 4:42 PM, Igor Fedorenko <i...@ifedorenko.com>
> > > wrote:
> > > >>
> > > >>> Why? How will we tell the original broken binaries from the new
> ones?
> > > >>>
> > > >>> On December 13, 2014 4:01:31 PM EST, Jason van Zyl <
> ja...@takari.io>
> > > >> wrote:
> > > >>>> No, it will be 3.2.4.
> > > >>>>
> > > >>>> On Dec 13, 2014, at 3:52 PM, Stephen Connolly
> > > >>>> <stephen.alan.conno...@gmail.com> wrote:
> > > >>>>
> > > >>>>> Iirc we said not reusing version numbers after a .0 so this will
> be
> > > >>>> 3.2.5,
> > > >>>>> yes?
> > > >>>>>
> > > >>>>> On Saturday, December 13, 2014, Jason van Zyl <ja...@takari.io>
> > > >>>> wrote:
> > > >>>>>
> > > >>>>>> The fixes have been made, I'll recut the release.
> > > >>>>>>
> > > >>>>>> On Dec 13, 2014, at 9:44 AM, Igor Fedorenko <
> i...@ifedorenko.com
> > > >>>>>> <javascript:;>> wrote:
> > > >>>>>>
> > > >>>>>>> I've already reintroduced DefaultJavaToolChain and Tycho is
> happy
> > > >>>> now
> > > >>>>>> [1].
> > > >>>>>>>
> > > >>>>>>> Tycho needs access to DefaultJavaToolChain#getJavaHome() which,
> > to
> > > >>>> the
> > > >>>>>>> best of my knowledge, is not available from any other API, is
> not
> > > >>>>>>> available through ToolchainManager.
> > > >>>>>>>
> > > >>>>>>> I don't believe Tycho references JavaToolChain interface. As a
> > side
> > > >>>>>>> note, in the future we should avoid case-only renames like
> > > >>>>>>> JavaToolChain->JavaToolchain, these cause problems on
> > > >>>> case-insensitive
> > > >>>>>>> filesystems, like the ones used by Windows and OSX.
> > > >>>>>>>
> > > >>>>>>> We don't distinguish between public and internal classes in
> > Maven,
> > > >>>> at
> > > >>>>>>> least not generally. There are few classes that are explicitly
> > > >>>> marked as
> > > >>>>>>> @provisional, like ArtifactDescriptorReaderDelegate for
> example,
> > > >>>> but
> > > >>>>>>> this is not enforced and majority of classes are not marked in
> > any
> > > >>>> way.
> > > >>>>>>> I agree we need to have a mechanism to distinguish between
> public
> > > >>>> and
> > > >>>>>>> internal classes and I have few ideas to do this, but I don't
> > think
> > > >>>> we
> > > >>>>>>> can do this retroactively. We have to keep most/all existing
> > > >>>> classes and
> > > >>>>>>> treat them as public API, unfortunately. Maybe mark them as
> > > >>>> deprecated
> > > >>>>>>> when we know we will likely change them in the future, but any
> > real
> > > >>>>>>> change has to wait Maven 4, and I am not sure we'll be able to
> > > >>>> afford
> > > >>>>>>> massive breakage even then.
> > > >>>>>>>
> > > >>>>>>> [1]
> > > >>>>>>
> > > >>>>
> > > >>
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=d6e45a5d56ab0facd36751ccee722db6a2006f50
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> Regards,
> > > >>>>>>> Igor
> > > >>>>>>>
> > > >>>>>>> On 2014-12-13, 9:04, Hervé BOUTEMY wrote:
> > > >>>>>>>> ok, I had a look at Tycho sources:
> > > >>>>>>>> this is something introduced recently (10/10/2014): IIUC,
> Tycho
> > > >>>> 0.22.0
> > > >>>>>> was
> > > >>>>>>>> released since then
> > > >>>>>>>>
> > > >>>>>>>> I'm surprised of tycho-core's ToolchainProvider: IIUC, that's
> a
> > > >>>> rewrite
> > > >>>>>> of a
> > > >>>>>>>> part of maven-toochains-plugin, depending on
> > > >>>> ToolchainManagerPrivate
> > > >>>>>> which is
> > > >>>>>>>> not part of public API
> > > >>>>>>>> IIUC, the intent was to get the configured toolchain: since
> > then,
> > > >>>> I
> > > >>>>>> wrote a
> > > >>>>>>>> little doc for that [1] to show how to use ToolchainManager to
> > do
> > > >>>>>> exactly that
> > > >>>>>>>> using normal Maven API
> > > >>>>>>>>
> > > >>>>>>>> Notice this won't fix everything, since:
> > > >>>>>>>> 1. Tycho needs JavaToochain, which has been renamed (Toolchain
> > vs
> > > >>>>>> ToolChain)
> > > >>>>>>>> 2. the interface doesn't offer expected getJavaHome() API
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Then you'll need to cast to DefaultJavaToolChain, which will
> > need
> > > >>>> to be
> > > >>>>>> added
> > > >>>>>>>> back to maven-core: I'll do it immediately.
> > > >>>>>>>>
> > > >>>>>>>> I don't know the Tycho community, but using ToolchainManager
> > would
> > > >>>> IMHO
> > > >>>>>> be
> > > >>>>>>>> more future-proof than writing ToolchainProvider
> > > >>>>>>>>
> > > >>>>>>>> Regards,
> > > >>>>>>>>
> > > >>>>>>>> Hervé
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> [1]
> > > >>>>>>
> > > >>>>
> > > >>
> > >
> >
> http://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/custom.html
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Le samedi 13 décembre 2014 09:13:50 Hervé BOUTEMY a écrit :
> > > >>>>>>>>> DefaultJavaToolChain? you mean the implementation?
> > > >>>>>>>>>
> > > >>>>>>>>> Can you give me pointers to the Tycho sources that use this
> > API?
> > > >>>>>>>>> (that's clearly not expected)
> > > >>>>>>>>>
> > > >>>>>>>>> I'm in favor of introducing deprecated DefaultJavaToolChain
> > > >>>>>>>>> that extends the new implementation, which is easy to do:
> just
> > > >>>> need to
> > > >>>>>>>>> understand how it is used in Tycho, since the class is
> supposed
> > > >>>> to be
> > > >>>>>> used
> > > >>>>>>>>> by JavaToolchainFactory (on only this one).
> > > >>>>>>>>>
> > > >>>>>>>>> Regards,
> > > >>>>>>>>>
> > > >>>>>>>>> Hervé
> > > >>>>>>>>>
> > > >>>>>>>>> Le vendredi 12 décembre 2014 18:38:44 Igor Fedorenko a écrit
> :
> > > >>>>>>>>>> Unfortunately, I have to take this back. The changes to
> > > >>>> toolchain
> > > >>>>>>>>>> broke Tycho and, short of using reflection, I don't see how
> > > >>>>>>>>>> to make Tycho work with maven 3.2.4 and earlier versions of
> > > >>>> Maven.
> > > >>>>>>>>>>
> > > >>>>>>>>>> For better or worse,
> > > >>>>>>>>>> org.apache.maven.toolchain.java.DefaultJavaToolChain was
> part
> > of
> > > >>>>>>>>>> Maven API since 2.x and I don't think we can just remove the
> > > >>>> class.
> > > >>>>>>>>>>
> > > >>>>>>>>>> I see two ways to fix this. Either we rename the classes
> back,
> > > >>>> which
> > > >>>>>> is
> > > >>>>>>>>>> probably the easiest. Or we introduce deprecated
> > > >>>> DefaultJavaToolChain
> > > >>>>>>>>>> that extends the new implementation.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Here is my -1 for releasing 3.2.4 in its current state.
> > > >>>>>>>>>>
> > > >>>>>>>>>> --
> > > >>>>>>>>>> Regards,
> > > >>>>>>>>>> Igor
> > > >>>>>>>>>>
> > > >>>>>>>>>> On 2014-12-12, 18:01, Igor Fedorenko wrote:
> > > >>>>>>>>>>> +1
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> --
> > > >>>>>>>>>>> Regards,
> > > >>>>>>>>>>> Igor
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On 2014-12-12, 16:54, Jason van Zyl wrote:
> > > >>>>>>>>>>>> Hi,
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Time to release Maven 3.2.4!
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Here is a link to Jira with 20 issues resolved:
> > > >>>>>>>>>>>>
> > > >>>>>>
> > > >>>>
> > >
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&versi
> > > >>>>>>>>>>>> on
> > > >>>>>>>>>>>> =20574
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Staging repo:
> > > >>>>>>>>>>>>
> > > https://repository.apache.org/content/repositories/maven-1102/
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> The distributable binaries and sources for testing can be
> > > >>>> found
> > > >>>>>> here:
> > > >>>>>>>>>>>>
> > > >>>>>>
> > > >>>>
> > >
> https://repository.apache.org/content/repositories/maven-1102/org/apach
> > > >>>>>>>>>>>> e/
> > > >>>>>>>>>>>> maven/apache-maven/3.2.4/
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Specifically the zip, tarball, and source archives can be
> > > >>>> found
> > > >>>>>> here:
> > > >>>>>>>>>>>>
> > > >>>>>>
> > > >>>>
> > >
> https://repository.apache.org/content/repositories/maven-1102/org/apach
> > > >>>>>>>>>>>> e/
> > > >>>>>>>>>>>> maven/apache-maven/3.2.4/apache-maven-3.2.4-bin.zip
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>
> > > >>>>
> > >
> https://repository.apache.org/content/repositories/maven-1102/org/apach
> > > >>>>>>>>>>>> e/
> > > >>>>>>>>>>>> maven/apache-maven/3.2.4/apache-maven-3.2.4-bin.tar.gz
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>
> > > >>>>
> > >
> https://repository.apache.org/content/repositories/maven-1102/org/apach
> > > >>>>>>>>>>>> e/
> > > >>>>>>>>>>>> maven/apache-maven/3.2.4/apache-maven-3.2.4-src.zip
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>
> > > >>>>
> > >
> https://repository.apache.org/content/repositories/maven-1102/org/apach
> > > >>>>>>>>>>>> e/
> > > >>>>>>>>>>>> maven/apache-maven/3.2.4/apache-maven-3.2.4-src.tar.gz
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Source release checksum(s):
> > > >>>>>>>>>>>> apache-maven-3.2.4-src.zip sha1:
> > > >>>>>>>>>>>> db5fb9feda693f05fe7effaf096d6cd4dd5eff44
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Staging site:
> > > >>>>>>>>>>>> http://takari.io/maven-3.2.4/
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Vote open for 72 hours.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> [ ] +1
> > > >>>>>>>>>>>> [ ] +0
> > > >>>>>>>>>>>> [ ] -1
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> The Maven Team
> > > >>>>>>>>>>>>
> > > >>>>>>
> > > >>>>
> > ---------------------------------------------------------------------
> > > >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >>>>>> <javascript:;>
> > > >>>>>>>>>>>> For additional commands, e-mail:
> dev-h...@maven.apache.org
> > > >>>>>> <javascript:;>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>
> > ---------------------------------------------------------------------
> > > >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >>>>>> <javascript:;>
> > > >>>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
> > > >>>>>> <javascript:;>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>
> > ---------------------------------------------------------------------
> > > >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >>>>>> <javascript:;>
> > > >>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
> > > >>>>>> <javascript:;>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>
> > ---------------------------------------------------------------------
> > > >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >>>>>> <javascript:;>
> > > >>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
> > > >>>>>> <javascript:;>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>
> > ---------------------------------------------------------------------
> > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >>>> <javascript:;>
> > > >>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
> > > >>>>>> <javascript:;>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>
> > ---------------------------------------------------------------------
> > > >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >>>> <javascript:;>
> > > >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
> > > >>>>>> <javascript:;>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>>
> > > >>>>>> Jason
> > > >>>>>>
> > > >>>>>> ----------------------------------------------------------
> > > >>>>>> Jason van Zyl
> > > >>>>>> Founder, Apache Maven
> > > >>>>>> http://twitter.com/jvanzyl
> > > >>>>>> http://twitter.com/takari_io
> > > >>>>>> ---------------------------------------------------------
> > > >>>>>>
> > > >>>>>> The modern conservative is engaged in one of man's oldest
> > exercises
> > > >>>> in
> > > >>>>>> moral philosophy; that is,
> > > >>>>>> the search for a superior moral justification for selfishness.
> > > >>>>>>
> > > >>>>>> -- John Kenneth Galbraith
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> Sent from my phone
> > > >>>>
> > > >>>> Thanks,
> > > >>>>
> > > >>>> Jason
> > > >>>>
> > > >>>> ----------------------------------------------------------
> > > >>>> Jason van Zyl
> > > >>>> Founder, Apache Maven
> > > >>>> http://twitter.com/jvanzyl
> > > >>>> http://twitter.com/takari_io
> > > >>>> ---------------------------------------------------------
> > > >>>>
> > > >>>> To think is easy. To act is hard. But the hardest thing in the
> world
> > > is
> > > >>>> to act in accordance with your thinking.
> > > >>>>
> > > >>>> -- Johann von Goethe
> > > >>>
> > > >>> --
> > > >>> Sent from my Android device with K-9 Mail. Please excuse my
> brevity.
> > > >>>
> > > >>>
> ---------------------------------------------------------------------
> > > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >>> For additional commands, e-mail: dev-h...@maven.apache.org
> > > >>>
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Jason
> > > >>
> > > >> ----------------------------------------------------------
> > > >> Jason van Zyl
> > > >> Founder, Apache Maven
> > > >> http://twitter.com/jvanzyl
> > > >> http://twitter.com/takari_io
> > > >> ---------------------------------------------------------
> > > >>
> > > >> Be not afraid of growing slowly, be only afraid of standing still.
> > > >>
> > > >> -- Chinese Proverb
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > >
> > > Thanks,
> > >
> > > Jason
> > >
> > > ----------------------------------------------------------
> > > Jason van Zyl
> > > Founder, Apache Maven
> > > http://twitter.com/jvanzyl
> > > http://twitter.com/takari_io
> > > ---------------------------------------------------------
> > >
> > > You are never dedicated to something you have complete confidence in.
> > > No one is fanatically shouting that the sun is going to rise tomorrow.
> > > They know it is going to rise tomorrow. When people are fanatically
> > > dedicated to political or religious faiths or any other kind of
> > > dogmas or goals, it's always because these dogmas or
> > > goals are in doubt.
> > >
> > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
