commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [all] Release preparation documentation
Date Wed, 07 Apr 2010 14:22:00 GMT
First, thanks for putting this together. Its great to have the docs updated.

While I have not looked at the document in detail, some high-level
comments below ...

On Mon, Apr 5, 2010 at 11:23 AM, Phil Steitz <> wrote:
> I have made my first attempt at updating the documentation here:
> 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 don't feel the need to argue about the method (be it manual, m2
release plugin, Nexus-based or something else). Ofcourse I care about
the bits that get posted, not so much how they got there.

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

The specifics and the scripts mentioned above constitute things that I
don't intend to follow by the letter. What the parent pom provides has
worked for me (the rc and release profiles).

I think this is captured somewhat in the following sentence on the
releases landing page:

  "Individual components may vary from these practices, but these
steps should prove sufficient for the majority of cases."

We should have it in bold and perhaps add another sentence that
elaborates on the bounds of the said variances. I will propose that
change when I get a chance.


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

View raw message