shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: Test 1.0.3 Artifacts (Round 2)
Date Sun, 20 Aug 2006 23:19:20 GMT
On 8/20/06, Sean Schofield <sean.schofield@gmail.com> wrote:
>
> I agree with both sides of this argument and to me, there is no ideal
> solution.  I think at this stage (serious but not final evaluation) we
> just keep -SNAPSHOT and ask users to download and review.  Before
> voting we can tweak the version number and label SVN.  We can ask
> committers to build from SVN tag and test and vote on that.


We can tweak the procedure next time ... but for this time I'm going to try
to role the final set of bits to propose for the vote this evening.  Can we
please hold up on commits until after I finish that, tag it, and update the
POMs for 1.0.4-SNAPSHOT?

Craig

At this point its unlikely there are any issues but if there are, the
> committers should be smart enough to know how to clear out their maven
> repo (and we can remind them with specific instructions.)  We
> definitely don't want to skip version numbers.
>
> So my proposal is to involve everyone in the beta testing but do not
> distribute the "final" version to vote on so we can prevent mass
> confusion.  If non committers want to participate they can build from
> the *tagged* svn version (not the trunk) and they do so at their own
> risk.
>
> Sean
>
> On 8/19/06, Craig McClanahan <craigmcc@apache.org> wrote:
> > On 8/19/06, Wendy Smoak <wsmoak@gmail.com> wrote:
> > >
> > > On 8/19/06, Craig McClanahan <craigmcc@apache.org> wrote:
> > >
> > > > Wendy wrote:
> > > > > A non-SNAPSHOT version should be built exactly once if at all
> > > > > possible.  Once it's in a repository, for all intents and purposes
> it
> > > > > *is* released and should not be changed.  Next time around let's
> > > > > just evaluate the -SNAPSHOT version until it's ready to tag and
> > > > > release.
> > > >
> > > > Isn't that why we have a test repository for snapshots?  Otherwise,
> > > you'd
> > > > only get one shot at publishing any particular version number, and
> we'd
> > > end
> > > > up with lots of holes in the sequence of version numbers ever
> actually
> > > > published.
> > >
> > > You can't have it both ways. :)  Either we do test builds and discard
> > > them if necessary, or we build release candidates as 1.1.3-RC1, -RC2,
> > > etc.
> >
> >
> > Or, we train people who are evaluating test builds about what to do.
> >
> > But we should not be building and re-building (and deploying to a
> > > public repository) anything that does not have a SNAPSHOT version
> > > number.
> > >
> > > We would never go back and 're-do' a release candidate, correct?
> >
> >
> > Agreed ... but evaluating release candidate bits (even if the sigs are
> > posted) is *not* the same as evaluating the "here's the real bits".  It
> puts
> > too much trust in the release manager not to screw up the final process,
> if
> > the vote is on a release candidate.
> >
> > On the other hand, if we're just interested in evaluating interim builds
> > that *might* end up being a release, we can just keep updating the
> snapshots
> > and say "please try again" ... iterate until satisfied ... without any
> > special "candidate" markings at all.
> >
> > Taking the next bits out of order...
> > >
> > > > I would prefer to see our release votes be about "these are the
> > > > exact bits that I want to push to the dist directory, and to
> ibiblio".
> > >
> > > Agreed.
> > >
> > > > The problem with evaluating the snapshots is we're trusting that
> nothing
> > > > goes wrong with the real build process after version numbers are
> updated
> > > in
> > > > the POMs.
> > > ...
> > > > We definitely don't want to be pushing test artifacts with
> non-SNAPSHOT
> > > > versions as a normal course of action, but in the roll-up to a
> release
> > > it
> > > > seems like the only way to do it.
> > >
> > > We review and fix the snapshots until we're happy with them.  (For
> > > MyFaces, I insert the last-changed svn revision number in the
> > > distribution filename.)
> > >
> > > Then we change the version number, build and deploy it once as 1.1.3,
> > > and vote on that.
> > >
> > > If there's a problem, move on to the next version.
> > >
> > > Can you explain why you think "missing" version numbers will be a
> problem?
> >
> >
> > Several issues:
> >
> > * Perception.  Skipping x.y.z release numbers is not a common practice
> >   across open source projects, and will create questions in some
> peoples's
> >   minds about what happened ... and maybe lead to doubts if the
> developers
> >   are really smart enough to be depended on.
> >
> > * Confusion.  Think of all the bug reports that have been marked as
> >   "will be included in 1.0.3".  We're *assuming* that people will
> understand
> >   that, if we skip 1.0.3 because of packaging issues in the test build,
> >   that 1.0.4 will include all of those changes.
> >
> > * More perception.  We've stated publicly we're working on a 1.0.3release.
> >   Skipping it, and doing a 1.0.4 instead, increases the perception that
> we
> >   never release what we say we're going to.  It could be perceived as
> giving
> >   us an excuse to *never* release because we can't get the build right.
> >
> > * Mechanics.  Admittedly nowhere near the amount of trouble that the
> > previous
> >   issues are, but it's a bunch of extra work (editing poms, setting up
> JIRA
> > version
> >   numbers, etc.), taking time that could be better spent getting the
> release
> > out
> >   in the first place.
> >
> > Craig
> >
> >
> > > > I'll look at it tomorrow afternoon, but I suspect renaming the files
> > > > > will be the easiest solution for 1.0.3.
> > >
> > > > I can live with that for this version.
> > >
> > > Sounds good. It's now tomorrow evening and I haven't had time yet. :(
> > >
> > > Thanks,
> > > --
> > > Wendy
> > >
> >
> >
>

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