On 20-Jul-08, at 11:26 AM, Vincent Siveton wrote:

Hi,

2008/7/19, Jason van Zyl <[EMAIL PROTECTED]>:
This is great as long as it does not become bureaucratic and onerous for
everyone to do a release.

Totally agree with you: it could be time consuming for the release
manager and for the committers which review...

How to prevent that is codify the process in the tooling. No one has ever, and never will, follow a workflow that is defined in a document. People are

Not agree with you. I think several PMCs follow the "Releasing A Maven
Project" doc.


Several possibly. But we've made many attempts to document the release process and it's generally not been finished or followed. I think what people have followed is the profile that was setup because they don't have any choice. If you can pick people up and put them in a defined workflow it's a lot easier for people. People either just don't read, or sometime misinterpret steps.

just people and most people themselves won't do it the same way twice unless
they do it often, and different people doing it the same? No chance.

Agree with you. More PMCs make releases, less they will read documents.

So if all this stuff was in a "pre-release-check" profile or something that was consistently applied and showed people how to fix things that would be awesome. Getting rid of all the crap that's collected in the wiki would be
great.

If you walked through all that stuff and created an actionable list to correct that's great. If I have to run 10 commands, that everyone else has to run people are just going to find variances and we're going to have
releases taking a week to fiddle around with the bits.

A first test of this toolchain could do an audit of all our plugins and
tell us how good (or bad) all the plugins are.

Reviewing Maven reports could be a good step. Unfortunately, some
report errors like clirr needs justifications why they fails...
Some active quality checks could be done directly in the reporting
profile. For instance, checkstyle plugin could have failsOnError set
to true. WDYT?

Checkstyle is good for suggestions, but I don't think things like PMD and Checkstyle should stop a release. That's getting a little too anal IMO. I'm fine with being notified, and even shamed, into documenting public APIs but I think for all our tools end-user documentation is more useful, and the IDE catches most of the other offenses.



Cheers,

Vincent


On 19-Jul-08, at 9:26 AM, Dennis Lundberg wrote:


I went and harvested the mojo-dev list for release vote comments, most of
the from Benjamin. Some are specific to plugins, but many are general.
Here's the list:


Inherit from the latest released parent to benefit from its improvements.

If the latest parent-SNAPSHOT has important fixes, copy these to the
components POM. Add a comment that they can be removed when parent X is
released.

Run "mvn docck:check" to make sure the documentation is good.

Check that a plugin's index page follows the template from the plugin
documentation standard.

To promote the best practice of specifying versions, POM snippets in the
docs should have a <version> element.

Check the Checkstyle/Clirr/CPD/PMD reports for any issues.

The POM must have an <scm> element, to make its "Source Repository" report
correct.

Use "mvn dependendcy:analyze" to find used but undeclared artifacts as
well as unused but declared artifacts.

For mojo parameters, using the annotation "default-value" is recommended
over "expression" when accessing POM elements like build directories [0, 1]
and boolean values.
Using "default-value" will make the expression show up nicely on the
mojo's info page. If the parameter should be set-able from the command line
an "expression" is needed.

[0]
http://www.nabble.com/Difference-between-default-value-and-expression-metatags-td5725581.html
[1]
http://www.nabble.com/Plugin-Parameters%3A-expression-vs.-default-value-td15109298.html

Investigate if a plugin suffers from any of the Common Bugs [2].

[2]
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html

If a component requires Java 1.5 to run, then this must be documented,
i.e. using the "target" option of the
compiler. For plugins this should be picked up by Maven Plugin Plugin 2.4
when generating the plugin-info.html. For non-plugins this must be
documented manually.

Updating the plugin to use the latest release of the Invoker Plugin (1.2)
could ease integration testing:
- convenient staging of plugin artifact into isolated local repo [3]
- separation of IT build output from version controlled directories [4]
- checking for failing IT builds [5]

[3]
http://maven.apache.org/plugins/maven-invoker-plugin/install- mojo.html
[4]
http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#cloneProjectsTo
[5]
http://maven.apache.org/plugins/maven-invoker-plugin/faq.html#question2


Vincent Siveton wrote:

Hi guys,
What are the minimalist things that we need to check for a good Maven
release?
Dennis points that we need to reduce Checkstyle errors, checking Clirr
report and licenses.
Any others ideas?
Cheers,
Vincent
---------- Forwarded message ----------
From: Dennis Lundberg <[EMAIL PROTECTED]>
Date: 16 juil. 2008 15:48
Subject: Re: [VOTE] Release Maven antrun plugin version 1.2
To: Maven Developers List <[email protected]>
Thanks for pushing for this release Carlos!
Unfortunately there are a couple of things that needs to be fixed
before we can release 1.2, for which I have to vote -1 to the current
release candidate.
- The POM is missing the license header (I fixed this in svn)
- The Source files have the old license headers (I fixed this in svn) - The documentation fix for MANTRUN-75 is not included in the 1.2 tag Here are some minor things that are nice to fix prior to the release,
all of which I have fixed in svn trunk.
- Use latest version of maven-plugin-plugin and maven-site-plugin
- Fix errors reported by Checkstyle
- Add missing scm info in the POM
The Clirr report [1] shows one error, one of the constructors for
AntPropertyHelper has changed the number of parameters. This was done in r374150 as part of the fix for MANTRUN-41. I guess that we can live
with that change. Do we need to document it?
[1]
http://maven.apache.org/plugins/maven-antrun-plugin-1.2/clirr-report.html
Carlos Sanchez wrote:

Hi,

9 issues fixed. Last release was 2.5 years ago


http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125&styleName=Html&version=12210

Staging repo:
http://people.apache.org/~carlos/staging-repo

Staging site:

http://maven.apache.org/plugins/maven-antrun-plugin-1.2/

Guide to testing staged releases:

http://maven.apache.org/guides/development/guide-testing- releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1


---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Dennis Lundberg

---------------------------------------------------------------------
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]



--
Dennis Lundberg


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language



---------------------------------------------------------------------
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
jason at sonatype dot com
----------------------------------------------------------

We know what we are, but know not what we may be.

  -- Shakespeare


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to