commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [all] Release preparation documentation
Date Mon, 05 Apr 2010 19:55:41 GMT
Phil Steitz a écrit :
> I have made my first attempt at updating the documentation here:

Thanks for this documentation, Phil.

I have one question and one comment.

In the "Create the release candidate" section, you write: "Note that the
release candidate is expected to have a name that includes RC so that
there is no confusion later between release candidate distributions and
the real distribution that is eventually released."

When using maven to build the artifacts, the names are taken from the
pom, which have been set to the final number as per instructions in a
previous section. So I understand maven will create
foo-1.2-various-suffixes and the release manager has to rename these
artifacts to foo-1.2-RC1-various-suffixes before uploading them to Is this correct ? Should this be explicitly explained
? Is their some black magic to do with the pom to have the -RC1 part
automatically added ?

The comment concerns the example message for voting. It refers to a
1.8.2 and 1.8.3 versions, which are inconsistent with the foo 1.2 example.


> Given that the previous docs were so out of date as to be pretty
> much worthless, I thought it best to push things along with CTR -
> actually "PTR" (p = publish).  I am sure there are some errors that
> I did not catch.  I would be most grateful to have those pointed out
> or fixed directly.  The site is now generated from commons-site in
> svn using m2 (no longer commons-build).
> The process for creating artifacts and pushing them to the mirrors
> uses the "manual" method (i.e., no release plugin) that Niall and I
> use to cut releases. We can argue about whether or not that is the
> right long-term direction, but I know this works and it is really
> not that complicated.  I included some specifics, including scripts,
> directory layouts, etc. that I use myself. I am certainly open to
> changing any/all of this, as long as the result is a set of
> instructions that are guaranteed to work.  I apologize for the fact
> that the instructions are at this point unix only.  Once we have the
> core content stabilized, it would be great to get either a Windows
> version or interspersed Windows instructions produced.
> One very important part that I have not really edited yet is the
> section at the bottom of the "prepare" page laying out what to look
> for in reviewing RCs.  It would be a *really good thing* if we could
> lay out there all and only what we collectively deem to be mandatory
> for RCs.  That would make it much easier for RMs and short-circuit
> some discussions on what is a show-stopper and what is not during
> release votes.  I am more than happy to document our consensus on
> these things. Patches welcome!
> Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message