Luc Maisonobe wrote: > Phil Steitz a écrit : >> I have made my first attempt at updating the documentation here: >> http://commons.apache.org/releases/index.html > > Thanks for this documentation, Phil. > > I have one question and one comment. > > In the "Create the release candidate" section, you write: "Note that the > release candidate is expected to have a name that includes RC so that > there is no confusion later between release candidate distributions and > the real distribution that is eventually released." > > When using maven to build the artifacts, the names are taken from the > pom, which have been set to the final number as per instructions in a > previous section. So I understand maven will create > foo-1.2-various-suffixes and the release manager has to rename these > artifacts to foo-1.2-RC1-various-suffixes before uploading them to > people.apache.org. Is this correct ? Should this be explicitly explained > ? Is their some black magic to do with the pom to have the -RC1 part > automatically added ?
Good catch. The sentence you are referring to is left from the previous version. It should either be deleted or made to refer only the the directory on people.apache.org. The statement in the previous section is the correct one - a couple of years ago, we moved to voting on the exact files that are going to the mirrors, so there is no renaming to be done. > > The comment concerns the example message for voting. It refers to a > 1.8.2 and 1.8.3 versions, which are inconsistent with the foo 1.2 example. > Another good catch. Stolen from Niall's recent BeanUtils VOTE ;) Thanks! Phil > Luc > >> 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! >> >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
