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
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.
[snip/]
I think we should have (2-g) and (2-f) above included as/in Release
Notes. Release notes can be deployed to the repo along with other
artifacts, so:
* 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)
* foo-1.0-release-notes.txt (updates/features in the artifact)
Cheers,
Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
