On 05/04/2010, 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. 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!
I think it might be useful to add a note regarding consistency between changes.xml, RELEASE-NOTES and JIRA. For example, if JIRA FOO-1234 is fixed in release 1.2, then IMO it should have a JIRA "fix" release of 1.2, and appear in the changes/RelNotes for 1.2. Conversely, if FOO-1234 is not fixed in release 1.2, then it should not have a JIRA fix of 1.2. This is to make it easy for users/developers to find which release contains the fix for a particular JIRA bug. It is not always so easy to find this out from checking release notes. It may be quite tedious to do the consistency check - and it may not always be 100% accurate - but I would hope to get agreement that it's worth documenting as a desirable goal. > 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
