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