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