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.ste...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
