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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
