Joakim Erdfelt wrote:
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
This is good, but some people out there are very sensitive to their
build tools dictating policy, so get a broad consensus on this before
shipping .
One issue is that I believe apache requires the PMC to vote on a built
up redistributable artifact. You dont vote before you release, you
build, stick it in staging, download it, test it and then finally say
"we ship this one".
I'd like to see POM auditing in there somewhere.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
