This is just a synopsis email about the future of the release process. Disclaimer: I am not attempting to set policy, just to get discussion going, document it, and work towards the ideal toolchain that make the future of apache releases smooth, consistent, and resilient
Desired End Goal: This discussion will revolve around the apache process for official releases of projects. 1) Releases are non-SNAPSHOT. 2) All releases shall be voted on. * Call a vote on the appropriate dev@ mailing list. * Wait 72 hours. * If unanimous +1 vote by 7 or more PMC members, then release can occur before 72 hour window is up. * Document the following in the vote: a) Project Name b) Project Version in Subversion. c) Desired Release Version ID. d) Expected Next Development Version ID. e) Age of development version (days since last non-snapshot release) f) Downstream snapshot dependencies that might cause problems. g) Jiras that have been closed/resolved for this release. f) Tasks that have been completed in SCM but do not appear in the Jira completion list. g) URL to jira completion report for this version. h) SCM revision being voted on. * If a change occurs to the project, the vote should be updated with the change and a new vote started. (this resets the 72 hours) This only consitutes changes that occur in the project itself, not downstream dependencies. 2) A Released project will contain the following files. Example directory contents of a project artifact 'foo', version '1.0' * foo-1.0.pom (pom / metadata for artifact) * foo-1.0.jar (actual binary artifact) * foo-1.0-sources.jar (source code for artifact) * foo-1.0-javadoc.jar (javadoc for artifact) 3) Each released file will be signed using the (apache.org) gpg signature of the commitor doing the release. 4) Each released file and gpg signature will have a hashcode generated for the file (managed by wagon) in SHA1 and MD5 format. 5) All jar files produced (binary, sources, and javadoc) will contain the following mandatory files: * META-INF/LICENSE.txt * META-INF/NOTICE.txt 6) All source files in the sources.jar files will contain the following header. ---(snip)--- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ---(snip)--- Techniques: 1) Original release plugin process. This is the release:prepare and release:perform technique. This technique does the following... a) Gather information about release IDs. * Release Version ID * Tag ID * Next Development Version ID a) Updates the poms in trunk to the provided Release Version ID. b) Tags these updated poms in subversion using the provided Tag ID. c) Updates the poms in trunk to the provided Next Development Version ID. d) Builds the release using the Subversion Tag. * clean * integration-test * install * site * deploy (binary and site) 2) Staged release process This process uses a staging workflow, there is no plugin for this process (yet). The benefits of this process is that a real binary is being blessed. This process also provides a way to resolve problems that occur during the release process. It goes like this... a) Call vote b) Wait on approval. c) Collect release information. * Release Version ID * Tag/Branch ID * Next Development Version ID c) 'prepare' release (occurs once) * Create a branch using provided Branch ID for this release. * Update poms in branch to provided Release Version ID. * Update poms in trunk to provided Next Development Version ID. d) 'stage' release (occurs 1 or more times) * Perform clean deploy. * Generate binary / sources / javadoc. * GPG Sign binary / sources / javadoc. * Generate Site. * Deploy binary / sources / javadoc, with signatures and hashcodes to staging directory. example: http://people.apache.org/~joakim/stage/repo/ * Deploy site to staging directory. example: http://people.apache.org/~joakim/stage/site/ * Generate 'need to bless', email to mailing list about staged artifacts and site. - Include changelog - Include links to staged artifacts - Show revision in SCM used for release - Show link to staged site - Show output of docck plugin - Show expanded forms of deliverables so they can be inspected for content (a jar listing?) - Show results of license header verification plugin. e) Wait on consensus from PMC for blessed artifacts. * if not-blessed, make changes required and re-do step d. f) 'bless' release (occurs once) * Tags the branch using provided Tag ID. * Move staged artifacts from staging location to real destination repository. * Move site from staging location to real site. * Send email announcing (to announce@ mailing lists) the release. - Include links to artifacts on real repository. - Include changelog Tools: The following tools are to aide in this process. Some of them are already developed, some are even released, others are just proposals. maven-gpg-plugin (released) This should be self explanatory. It signs the attached artifacts due to be released. maven-javadoc-plugin (released) This generates both the raw javadoc used in the site, but also the javadoc.jar file for the project (used by the IDEs out there) maven-source-plugin (released) This generates the sources.jar file (used by the IDEs out there) maven-remote-resource-plugin (released) This will copy the appropriate Apache process LICENSE.txt and NOTICE.txt files into place for the released artifacts. maven-deploy-plugin (SNAPSHOT, work has been done) This has been specially modified to allow for an alternate deployment location used by the staging process. maven-license-plugin (SNAPSHOT, 80% functional, needs help) This has the ability to check for the existance of the license header in the source files (java/xml/properties/css/html/jsp, etc...) and the ability to inject the license in those files that do not have the correct one. repositorytools-maven-plugin (SNAPSHOT, exists at codehaus) This has a :copy goal that allows for the staged artifacts to be moved from the staging location into the real location, while merging metadata.xml file contents and the like. maven-docck-plugin (released) This is to ensure the documentation requirements of the projects. maven-release-staging-plugin (not written) This could be useful to bundle up the various other plugins into an simple goal. possible goals :prepare, :stage, :bless. This plugin could also ensure the configuration parameters needed in the settings.xml file to perform a release. maven-apache-deploy-check-plugin (not written) This tool could check the attached artifacts to see if they conform to the current set of rules for releases. It can check for the existance and content of the LICENSE.txt and NOTICE.txt files, that javadoc.jar and sources.jar artifacts are attached, that the signature files are attached, and that your signature is even present on the public KEYS files as well as on a public gpg server. - Joakim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]