On Wed, Sep 19, 2012 at 9:29 PM, Chris Graham <[email protected]> wrote: > On Thu, Sep 20, 2012 at 5:46 AM, Benson Margulies > <[email protected]>wrote: > >> On Wed, Sep 19, 2012 at 3:02 PM, Anders Hammar <[email protected]> wrote: >> > Isn't it a little bit of overkill to do a release for this? Why not >> > just simply replace that page on the site? Keep it simple... >> >> Well, I have always had mixed feelings about the fact that the doc for >> each component and plugin is so tightly tied to the release process. >> > > It's not tied per-se. It calls the site process. Having the most update to > date release doco generated and published as part of the release process > makes good sense. > > >> The alternative is to checkout the tag, tweak the pom, and build and >> deploy the site. >> >> But this reminds me of another ancient peeve: the process of making >> the release tends to make the SCM page point at the release tag, not >> the trunk. I wish it were otherwise. >> > > I could not disagree with you more.
Well, I think it's clear that you could disagree with me more, since you have on other subjects. > > The doco is generated by the release. The release is tagged. The links > point to the tag. > > It is as it should be; it makes perfect sense. There are (potentially) two parts to the SCM page. One says, "where will you find this release in SCM." The other says, "If you want to join the development community, here's what you check out" What I want is for the output of MPIR to clearly and distinctly set out both. > > >> >> >> > >> > /Anders >> > >> > On Wed, Sep 19, 2012 at 7:58 PM, Benson Margulies <[email protected]> >> wrote: >> >> A typical thing for people to do is to google for maven-foo, find the >> >> published 'site' doc, and then go to the SCM page. >> >> >> >> So, while we've got various ways to rescue people from the confusion >> >> that might ensue if they do the above before the next release, I'd >> >> suggest a point release or some other scheme just to get those scm >> >> pages upgraded. >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
