shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: Test 1.0.3 Artifacts (Round 2)
Date Sun, 20 Aug 2006 03:11:10 GMT
On 8/19/06, Wendy Smoak <> wrote:
> On 8/19/06, Craig McClanahan <> 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.3 release.
  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
  issues are, but it's a bunch of extra work (editing poms, setting up JIRA
  numbers, etc.), taking time that could be better spent getting the release
  in the first place.


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

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