commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [all] Release preparation documentation
Date Fri, 09 Apr 2010 01:25:18 GMT
Rahul Akolkar wrote:
> 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 <phil.steitz@gmail.com> wrote:
>> I have made my first attempt at updating the documentation here:
>> http://commons.apache.org/releases/index.html
>>
>> 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.
> <snip/>
> 
> 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.
>>
> <snap/>
> 
> 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."

+1 absolutely not meant to be prescriptive, just a set of steps that
are known to work if followed exactly and a little time saving for
RMs who want to use them.

Phil
> 
> 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.
> 
> -Rahul
> 
> 
>> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message