shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wendy Smoak" <wsm...@gmail.com>
Subject Re: Test 1.0.3 Artifacts (Round 2)
Date Sun, 20 Aug 2006 01:27:03 GMT
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.

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?

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?

> > 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
View raw message