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: [VOTE] Should we respin CANCELLED releases with the same version number?
Date Thu, 30 May 2013 13:28:47 GMT
No, I'd cut off my own hand with a blunt teaspoon before I did that.

On Thu, May 30, 2013 at 3:20 PM, Chris Graham <chrisgwarp@gmail.com> wrote:

> No, not at all.
>
> We're talking about removing the latest tag whilst in the process of
> voting.
>
> My reading of what you wrote, was that you were suggesting to
> retroactively go back and remove tags that are not the latest release.
>
> Which I believe is against the apache rules.
>
> -Chris
>
> Sent from my iPhone
>
> On 30/05/2013, at 10:06 PM, Fred Cooke <fred.cooke@gmail.com> wrote:
>
> > Point missed. You said:
> >
> > It's a huge change; as if you do not delete, you now have broken
> 'releases'
> >> in a SCM somwhere, and that is radically different to what is currently
> >> there.
> >>
> >
> > And my point was, it's no change at all, there are already broken
> > "releases" (without the quotes) in an SCM somewhere. So it's no different
> > at all, certainly not radically different.
> >
> > Fred.
> >
> > PS, Stephen, you were lucky! I only got a plate with some cookie crums
> and
> > an empty glass smelling of lagavulin :-p
> >
> > On Thu, May 30, 2013 at 1:58 PM, Chris Graham <chrisgwarp@gmail.com>
> wrote:
> >
> >> No, by their own rules, if the vote passed, then it's  'valid' release.
> >>
> >> That fact that we have more than one release of anything means that we
> >> sometimes get it wrong.
> >>
> >> -Chris
> >>
> >>
> >> On Thu, May 30, 2013 at 8:38 PM, Fred Cooke <fred.cooke@gmail.com>
> wrote:
> >>
> >>> Are you saying that tags for 2.1 and 2.2.0 of Maven itself should be
> >>> deleted because those versions are broken? A tag isn't a guarantee of
> >>> correctness/non-brokenness, it's just a *permanent* record of what a
> >>> particular version contained. The concept of immutability is pretty
> core
> >> to
> >>> Maven (at least in my mind). When I first witnessed the deletion of
> tags
> >>> and re-spinning of versions some months ago it was the most disturbing
> >>> thing that's happened to me since I found out that Santa Claus wasn't
> >> real.
> >>> This is (supposed to be) the pinnacle of release engineering, setting
> an
> >>> example for all to follow, and it's breaking its own rules. I was,
> quite
> >>> literally, very sad. This seems like an opportunity to fix the
> situation.
> >>> I'm baffled by some of the things being said, though.
> >>>
> >>> On Thu, May 30, 2013 at 12:26 PM, Chris Graham <chrisgwarp@gmail.com>
> >>> wrote:
> >>>
> >>>> One more thing to consider:
> >>>>
> >>>> It's a huge change; as if you do not delete, you now have broken
> >>> 'releases'
> >>>> in a SCM somwhere, and that is radically different to what is
> currently
> >>>> there.
> >>>>
> >>>> I should be able to check anything out now from a tag, build it and
> >> have
> >>> it
> >>>> work.
> >>>>
> >>>> If we allow broken tags, then we could be frustrating a lot of people.
> >>>>
> >>>> It's a huge change of process.
> >>>>
> >>>> And for me, I prefer not to introduce it.
> >>>>
> >>>> We also have maven's concept of immutability, which is a reason NOT
to
> >>>> allow the reuse of numbers; however, that does not appear to have been
> >>> too
> >>>> much of a problem up until now.
> >>>>
> >>>> -Chris
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Thu, May 30, 2013 at 7:55 PM, Stephen Connolly <
> >>>> stephen.alan.connolly@gmail.com> wrote:
> >>>>
> >>>>> On 30 May 2013 10:30, Chris Graham <chrisgwarp@gmail.com>
wrote:
> >>>>>
> >>>>>> Thank you Stephen for taking the time to explain.
> >>>>>>
> >>>>>> To me, the key critical bits are:
> >>>>>>
> >>>>>> 1. The full normal tag is created, and deleted if failed. If
the
> >>>> release
> >>>>>> process fails (as in release:prepare/release:perform) we often
have
> >>> to
> >>>>>> delete the tag and manually re-run it anyway.
> >>>>>>
> >>>>>
> >>>>> Well to my mind that is also part of the issue....
> >>>>>
> >>>>> If we accept that failed tags get deleted, then we should respin
> >>> reusing
> >>>>> the same version number until we have a non-failed tag (irrespective
> >> of
> >>>> the
> >>>>> reason for the failure)
> >>>>>
> >>>>> If we don't reuse version numbers, it should be ever, in which case
> >> if
> >>>>> release:prepare produces a tag that *cannot* complete release:perform
> >>> (as
> >>>>> opposed to just a failure for a single run of release:perform) then
> >> we
> >>>>> would not delete the tag and run release:prepare for the next version
> >>>>> number.
> >>>>>
> >>>>> In that sense I don't see this as a critical bit... rather I see
it
> >> as
> >>>> part
> >>>>> of what should be covered by the vote.
> >>>>>
> >>>>>
> >>>>>> 2. The copying process to get it in the wild is manual and post
> >> vote.
> >>>>>>
> >>>>>
> >>>>> Not quite true, the artifacts are in the wild... just in a staging
> >>>>> repository from which they can be deleted. The copy to dist is a
> >> legal
> >>>>> requirement to ensure the legal protections that the ASF provides
> >>> remain
> >>>> in
> >>>>> force (this is also why the PMC have binding votes, and why the
PMC
> >> has
> >>>> to
> >>>>> concern itself with annoying pesky things like ensuring that the
> >>>> NOTICE.txt
> >>>>> has correct content and that files have the correct license
> >> headers...
> >>> I
> >>>>> may not, in the past, have fully appreciated the reasons for or
the
> >>> needs
> >>>>> for these things... but since becoming a member of the ASF [with
the
> >>>> legal
> >>>>> responsibilities that come with that] I have gained a different
> >>>>> perspective).
> >>>>>
> >>>>> But there is always concern from people that they will end up with
> >>> their
> >>>>> local repository corrupted as a side-effect of testing.
> >>>>>
> >>>>> For instance, suppose there is a fix related to how some component
> >>> works
> >>>>> behind a proxy. That may well require you to add the staging
> >> repository
> >>>> to
> >>>>> your corporate proxy repository (because the machines you want to
> >> test
> >>>>> from, and perhaps even the scenario you want to test, are required
to
> >>>> have
> >>>>> a <mirrorOf>*</mirrorOf> in their settings.xml)... in
such a case you
> >>>> will
> >>>>> end up with the situation that the test machines have downloaded
the
> >>>>> artifacts into their local repository cache *and* even with the
> >>>> repository
> >>>>> source validation that Maven 3.x brings to the table, you will need
> >> to
> >>>>> manually purge those artifacts from your local repository cache
> >>> *because*
> >>>>> the <mirrorOf>*</mirrorOf> will be forcing the source
of those
> >> release
> >>>>> artifacts to be unchanged.
> >>>>>
> >>>>> Now one could argue that you shouldn't be adding the staging repo
to
> >>> your
> >>>>> proxy in the first place, and instead you should create a special
> >> proxy
> >>>> on
> >>>>> your repository manager that adds in the staging repo on top of
the
> >>>> normal
> >>>>> proxy and update the settings.xml to use this new mirrorOf source...
> >>> but
> >>>>> that will force everything to be re-downloaded into the local cache
> >>> *and*
> >>>>> there are test circumstances where one might fear that such a change
> >>>> could
> >>>>> affect the validity of your testing.
> >>>>>
> >>>>> The above, to my mind, is the primary driver for never reusing
> >> version
> >>>>> numbers... whether it is worthy of the change is for all to decide...
> >>>>>
> >>>>> My current thinking is though:
> >>>>>
> >>>>> * if we allow deleting tags because the tag won't complete
> >>>> release:perform,
> >>>>> then we should re-use version numbers.
> >>>>>
> >>>>> * if we don't allow re-using version numbers, then we should not
> >> allow
> >>>>> deleting tags *just* because the tag won't complete release:perform.
> >>>>>
> >>>>> And I am considering whether I want to change my vote ;-)
> >>>>>
> >>>>>
> >>>>>> Given that, I have no problem with respinning a release using
the
> >>> same
> >>>>>> version, which is, essentially what we have been doing.
> >>>>>>
> >>>>>> This is very similar to what I do for the day job. But not the
> >> same.
> >>> In
> >>>>> the
> >>>>>> day job, we through away a release and just create a new one.
> >>>>>>
> >>>>>> Why the difference?
> >>>>>>
> >>>>>> Simple, the audience for the day job is limited, and the decision
> >> to
> >>>>>> release is driven by the tech lead and immediate.
> >>>>>>
> >>>>>> There is no voting process.
> >>>>>>
> >>>>>> In this OS world, we are talking about release X.Y.Z (or whatever)
> >>> and,
> >>>>>> personally, I remember X.Y.Z. I would quickly get confused if
I had
> >>> to
> >>>>>> constantly remember that X.Y.Z is now X.Y.(Z+N).
> >>>>>>
> >>>>>> Additionally, the vote remains open for a period of time, and
I
> >> would
> >>>> get
> >>>>>> lost with the constantly changing numbers. Note, this is not
the
> >> same
> >>>> as
> >>>>>> saying anything about skipped public version numbers.
> >>>>>>
> >>>>>> For the same reason, I would recommend offering different
> >> approaches
> >>> to
> >>>>>> core/plugins/whatever: let's not complicate things.
> >>>>>>
> >>>>>> So, to that end,
> >>>>>>
> >>>>>> -1 (ie respin) for all
> >>>>>>
> >>>>>> (non binding)
> >>>>>>
> >>>>>> -Chris
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, May 30, 2013 at 5:11 PM, Stephen Connolly <
> >>>>>> stephen.alan.connolly@gmail.com> wrote:
> >>>>>>
> >>>>>>> On Thursday, 30 May 2013, Chris Graham wrote:
> >>>>>>>
> >>>>>>>> What do we currently do for plugins?
> >>>>>>>
> >>>>>>> What do we currently do for core?
> >>>>>>>> Is there in difference in the approach taken?
> >>>>>>>
> >>>>>>>
> >>>>>>> No difference. In each case we currently respin failed votes
> >>> reusing
> >>>>> the
> >>>>>>> version number until we get an actual successful vote.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> We call for a vot for vX.Y.Z of <arbitrary plugin>
(plugins's
> >>>>> [recently
> >>>>>>> at
> >>>>>>>> least] do not appear to go throught he beta/RC phases).
> >>>>>>>
> >>>>>>>
> >>>>>>> That is down to not really having new core plugins recently,
and
> >>> the
> >>>>> size
> >>>>>>> of changes being such that the release manager felt there
was no
> >>> need
> >>>>> for
> >>>>>>> an alpha/beta
> >>>>>>>
> >>>>>>> Because of the switch from sonatype aether to eclipse aether
> >> *and*
> >>>> the
> >>>>>>> exposing of the aether API to plugins, for Maven 3.1.0 jumping
> >>>> straight
> >>>>>> to
> >>>>>>> 3.1.0 was deemed too risky by the release manager, hence
> >>>> 3.1.0-alpha-1.
> >>>>>>>
> >>>>>>> Personally, given the lack of review the 3.1.0-SNAPSHOTs
were
> >>>> getting,
> >>>>>> this
> >>>>>>> was probably a wise plan... However I think quite a few
people
> >> have
> >>>> put
> >>>>>>> their eyes on the code by now, so *if* I was the release
manager,
> >>> I'd
> >>>>> be
> >>>>>>> tempted to head straight for 3.1.0... Thankfully I am not
release
> >>>>> manager
> >>>>>>> for this release, so not my problem ;-)
> >>>>>>>
> >>>>>>> (Note: the release manager is just whoever stands up and
says "I
> >>> want
> >>>>> to
> >>>>>>> cut a release of XYZ"... Can change with every release,
or stay
> >>>> mostly
> >>>>>> the
> >>>>>>> same. Eg Kristian has been release manager for Surefire
by
> >>>> consistently
> >>>>>>> stepping up and cutting releases, but if any other committer
> >> wanted
> >>>> to
> >>>>>> run
> >>>>>>> a release they can step up at any time... It's actually
something
> >>> we
> >>>>>>> encourage newer committers to do (usually starting with
smaller
> >>>> plugins
> >>>>>>> though) so that they can get a feel for how our release
process
> >>> works
> >>>>>>> (learn by doing))
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Can someone please spell out a sequence of events (by
time) as
> >> to
> >>>>> what
> >>>>>>>> happens through the entire process? From prep to vote
to ending
> >>> up
> >>>> in
> >>>>>>>> central.
> >>>>>>>>
> >>>>>>>> Slightly simplified, and there are differences for components
> >> vs
> >>>>>> plugins
> >>>>>>> vs core, but essential principle remains close to this
> >>>>>>>
> >>>>>>> 1. Run `mvn release:prepare release:perform`
> >>>>>>> 2. Send the "[vote]" email
> >>>>>>> 3. Wait 72h (or longer if not enough binding votes and the
> >> release
> >>>>>> manager
> >>>>>>> thinks some more binding votes will turn up)
> >>>>>>> 4. On nexus, promote the staging repo
> >>>>>>> 5. Update JIRA versions
> >>>>>>> 6. Update the component's site (and for plugins the table
of
> >> plugin
> >>>>>>> versions)
> >>>>>>> 7. Copy the artifacts to dist
> >>>>>>> 8. Wait for "the sync" to central
> >>>>>>> 9. Send "[ann]" email
> >>>>>>>
> >>>>>>> And the same sequnce, but for a failed vote, and it's revoting
> >>> (we've
> >>>>>> used
> >>>>>>>> the same version no again, here, have we not?)
> >>>>>>>
> >>>>>>>
> >>>>>>> After step 3, we currently delete the tag, go back to step
1. And
> >>>>> release
> >>>>>>> again reusing the same version number from the first time.
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> -Chris
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, May 30, 2013 at 6:11 AM, Fred Cooke <
> >>> fred.cooke@gmail.com
> >>>>>>> <javascript:;>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -1 for actual releases: it would create more
mess imo for
> >> end
> >>>>> users
> >>>>>>> if
> >>>>>>>>>> there's many bizarre jumps in numbering
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The thing with this argument is that it's very,
very weak.
> >> If a
> >>>>>> missed
> >>>>>>>>> version confuses a user, they're basically brain-dead.
> >> Assuming
> >>>>> your
> >>>>>>>> users
> >>>>>>>>> are brain dead is _always_ dangerous. Assuming the
users or a
> >>>>>>>> _development_
> >>>>>>>>> tool are brain-dead is that in and of itself IMO.
> >>>>>>>>>
> >>>>>>>>> A random example from central that I gave to Robert
earlier:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> http://search.maven.org/#search|gav|1|g%3A%22antlr%22%20AND%20a%3A%22antlr%22
> >>>>>>>>>
> >>>>>>>>> I don't know about the rest of you... but I'm not
confused by
> >>> the
> >>>>>>> absence
> >>>>>>>>> of 2.7.3 in any way shape or form. I'm additionally
not
> >>> confused
> >>>> by
> >>>>>> the
> >>>>>>>>> absence of 2.7.8, 2.7.9, 2.7.10, etc, nor 2.8.*
nor 2.9.*
> >> It's
> >>>>>>>> meaningless
> >>>>>>>>> to me that they're absent. I use and test a version
(usually
> >>>>> latest)
> >>>>>>> and
> >>>>>>>>> verify it functions adequately for my needs, then
I depend on
> >>> it
> >>>>> (dep
> >>>>>>> or
> >>>>>>>>> plugin equally) and that's it. If I find a flaw,
or need to
> >>> use a
> >>>>> new
> >>>>>>>>> feature, then I can go looking for the best version
that is
> >>>>>> compatible
> >>>>>>>> with
> >>>>>>>>> my setup, that contains it (again, likely latest,
API change
> >>> not
> >>>>>>>>> withstanding).
> >>>>>>>>>
> >>>>>>>>> Being worried about developers being confused by
a
> >>> non-sequential
> >>>>> set
> >>>>>>> of
> >>>>>>>>> binaries to choose from is bizarre at best. Developers,
even
> >>> the
> >>>>> bad
> >>>>>>>> ones,
> >>>>>>>>> are generally a fairly intelligent bunch.
> >>>>>>>>>
> >>>>>>>>> This is not winamp! :-p (nor VLC)
> >>>>>>>>>
> >>>>>>>>> Fred.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Sent from my phone
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

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