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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

Reply via email to