+1 on keeping all the release notes online!! On Sun, Jul 19, 2009 at 8:07 AM, Jason van Zyl<[email protected]> wrote: > Just getting back after being sick for a week. > > On 10-Jul-09, at 7:18 PM, Brett Porter wrote: > >> sorry, these changes should have been on a branch. I'll move that across >> now so that trunk is still deployable. I'm heading out now but I can respond >> to these issues later. >> > > No biggie. I just think the notes being aggregated to be a good thing. > Doesn't mean we can't do both if it's still convenient. > >> On 11/07/2009, at 12:27 AM, Jason van Zyl wrote: >> >>> >>> On 10-Jul-09, at 1:48 AM, Brett Porter wrote: >>> >>>> Hi, >>>> >>>> I've committed some changes that I'd like reviewed to go forward with >>>> which makes Maven releases easier. >>>> >>>> 1) see >>>> http://maven.apache.org/docs/2.0.11-RC1-SNAPSHOT/release-notes.html (may >>>> not >>>> be present yet due to proxying), and relevant commits in that RC branch >>>> >>>> 2) see commits in site branch. >>>> >>>> The basic approach is this: >>>> >>>> * push all release notes into docs/$version/release-notes.html instead >>>> of the consolidated older format and add a page to list them in order >>>> >>> >>> So if someone wants to see the historical list of changes they will need >>> to look at N documents? The consolidated format is good as the history of >>> change is kept in one place which is what people looking to migrate want to >>> see. >>> >>>> * move the release notes for all future versions of Maven into the Maven >>>> tree itself. This means that you can create/edit them as they are a >>>> snapshot >>>> without messing up the site, and publish them automatically with the >>>> release. >>>> >>> >>> Again these changes span versions. I have no problem keeping these in SVN >>> somewhere but chopping up the release notes into multiple documents makes it >>> really hard to view the high level changes over time. If folks want to see >>> exacting detail per version they can get this from JIRA. The release notes >>> should be cohesive spanning multiple versions. They at least need to be in >>> an aggregated form somewhere. >>> >>>> * set the release up to publish the above site and javadoc/xref at >>>> release perform time (this is before the vote, but as it is versioned it is >>>> not going to be live) >>>> >>> >>> If you mean coupling the publishing of site during the release then -1. >>> >>> The site publishing cannot be coupled to the actual release. The release >>> of the binaries should not fail because of some aggregation, ordering or >>> some other problem with the reporting/site system. Whoever is doing the >>> release can do this in two steps. Some external system could orchestrate >>> this but the actual release itself should not couple the site publishing the >>> distribution of binaries. >>> >>>> * consolidate all version specification for the main site in pom.xml, so >>>> only those properties need to be edited (I removed 2.1.x, so we have the >>>> currentStableVersion - 2.2.0, current20xVersion - 2.0.10, and a list of all >>>> releases for generating the previous release notes, + corresponding dates >>>> for the current releases) >>>> >>>> * remove use of symlink for "current" and instead filter those >>>> properties into .htaccess >>>> >>>> This means that to do a release, assuming it works (which I'll test with >>>> 2.0.11), it's only the release:prepare / perform cycle + upload binaries to >>>> www.apache.org (to be automated) + site/pom.xml edit and site-deploy. >>>> >>>> The downside of the separate site approach is that the release notes >>>> drop the main navigation (but there is a "Documentation" link back to the >>>> main site). I don't think this is a bad thing. >>>> >>>> Any objections to continuing this approach with Maven 2.2.x, and perhaps >>>> making similar attempts on the plugins? >>>> >>> >>> As bad as the site is now people are accustomed at least to the >>> structure. I really think you should think hard about wanting to flip all >>> this around again. The problem on the site is the content, not the >>> structure. There is actually far too much structure are far too little >>> meaningful information. I honestly don't think this is the best use of >>> anyone's time and the focus should be simplification and clarifying the >>> existing content more then anything. >>> >>>> Cheers, >>>> Brett >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> http://twitter.com/SonatypeNexus >>> http://twitter.com/SonatypeM2E >>> ---------------------------------------------------------- >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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] >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/SonatypeNexus > http://twitter.com/SonatypeM2E > ---------------------------------------------------------- > > First, the taking in of scattered particulars under one Idea, > so that everyone understands what is being talked about ... Second, > the separation of the Idea into parts, by dividing it at the joints, > as nature directs, not breaking any limb in half as a bad carver might. > > -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) > > > --------------------------------------------------------------------- > 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]
