2009/4/23 Clement Escoffier <[email protected]> > Stuart, > > I read you page, thanks for documenting it. IT's pretty nice. But I wonder > about md5, sha1 ... beautification? > It is no more required ? > > It seems that we can't really beautify the signatures with this new release > process. >
that's correct - but we only really beautified them so it was easier for Richard to check them ;) thankfully the new script I added (check_staged_release.sh) will automatically download and check the signatures/digests without needing them beautified, so it's just as easy to check > Clement > > On 22.04.2009, at 19:21, [email protected] wrote: > > Page Edited : FELIX : Release Management (Nexus) >> Release Management (Nexus) has been edited by Stuart McCulloch (Apr 22, >> 2009). >> >> (View changes) >> >> Content: >> This is the new release process for Apache Felix, based on the updated >> Maven process >> >> Prerequisites >> To prepare or perform a release you MUST BE at least an Apache Felix >> Committer. >> >> each and every release must be SIGNED; your public key should be added to >> http://www.apache.org/dist/felix/KEYS (see Appendix A) >> your public key should also be cross-signed by other Apache committers >> (not required, but suggested) >> when preparing the release on Mac OS X, make sure you read Appendix B >> before continuing >> make sure you have all Apache servers defined in your settings.xml >> In the past we staged release candidates on our local machines using a >> semi-manual process. Now that we inherit from the Apache parent POM version >> 5, a repository manager will automatically handle staging for you. This >> means you now only need to specify your GPG passphrase in the release >> profile of your ${user.home}/.m2/settings.xml: >> >> <settings> >> ... >> <profiles> >> <profile> >> <id>release</id> >> <properties> >> <gpg.passphrase> <!-- YOUR KEY PASSPHRASE --> </gpg.passphrase> >> </properties> >> </profile> >> </profiles> >> ... >> </settings> >> Everything else has been configured in the latest Felix parent POM: >> >> <parent> >> <groupId>org.apache.felix</groupId> >> <artifactId>felix-parent</artifactId> >> <version>1.2.0</version> >> <relativePath>../pom/pom.xml</relativePath> >> </parent> >> Staging the Release Candidates >> First prepare your POMs for release: >> >> make sure there are no snapshots in the POMs to be released >> check that your POMs will not lose content when they are rewritten during >> the release process >> mvn release:prepare -DdryRun=true >> diff the original pom.xml with the one called pom.xml.tag to see if the >> license or any other info has been removed. This has been known to happen if >> the starting <project> tag is not on a single line. The only things that >> should be different between these files are the <version>and <scm> elements. >> If there are any other changes, you must fix the original pom.xml file and >> commit before proceeding with the release >> publish a snapshot >> $ mvn deploy >> ... >> [INFO] [deploy:deploy] >> [INFO] Retrieving previous build number from apache.snapshots.https >> ... >> if you experience an error during deployment like a HTTP 401 check your >> settings for the required server entries as outlined in the Prerequisites >> be sure that the generated artifacts respect the Apache release rules: >> NOTICE and LICENSE files should be present in the META-INF directory within >> the jar. For -sources artifacts, be sure that your POM does not use the >> maven-source-plugin:2.0.3 which is broken. The recommended version at this >> time is 2.0.4 >> you should verify the deployment under the snapshot repository on Apache >> prepare the release >> mvn release:clean >> mvn release:prepare >> preparing the release will create the new tag in SVN, automatically >> checking in on your behalf >> stage the release for a vote >> mvn release:perform >> the release will automatically be inserted into a temporary staging >> repository for you, see the Nexus staging documentation for full details >> close the staging repository >> login to https://repository.apache.org using your Apache SVN credentials. >> Click on Staging on the left. Then click on org.apache.felix in the list of >> repositories. In the panel below you should see an open repository that is >> linked to your username and IP. Right click on this repository and select >> Close. This will close the repository from future deployments and make it >> available for others to view. If you are staging multiple releases together, >> skip this step until you have staged everything >> verify the staged artifacts >> if you click on your repository, a tree view will appear below. You can >> then browse the contents to ensure the artifacts are as you expect them. Pay >> particular attention to the existence of *.asc (signature) files. If you >> don't like the content of the repository, right click your repository and >> choose Drop. You can then rollback your release (see Canceling the Release) >> and repeat the process >> note the staging repository URL (especially the number at the end of the >> URL) you will need this in your vote email >> Starting the Vote >> Propose a vote on the dev list with the closed issues, the issues left, >> and the staging repository - for example: >> >> To: "Felix Developers List" <[email protected]> >> Subject: [VOTE] Release Felix XXX version Y.Z >> >> Hi, >> >> We solved N issues in this release: >> http://issues.apache.org/jira/... >> >> There are still some outstanding issues: >> http://issues.apache.org/jira/... >> >> Staging repository: >> https://repository.apache.org/content/repositories/felix-staging-[YOUR >> REPOSITORY ID]/ >> >> You can use this UNIX script to download the release and verify the >> signatures: >> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >> >> Usage: >> sh check_staged_release.sh [YOUR REPOSITORY ID] /tmp/felix-staging >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] -1 Veto the release (please provide specific comments) >> >> This vote will be open for 72 hours. >> to get the JIRA release notes link, browse to the FELIX JIRA page, select >> Release Notes and choose the relevant sub-project release and format (HTML) >> to get the list of issues left in JIRA, select the Open Issues tab on the >> main FELIX page, and select the relevant sub-project. >> Wait for the Results >> From Votes on Package Releases: >> >> Votes on whether a package is ready to be released follow a format similar >> to majority approval – except that the decision is officially determined >> solely by whether at least three +1 votes were registered. Releases may not >> be vetoed. Generally the community will table the vote to release if anyone >> identifies serious problems, but in most cases the ultimate decision, once >> three or more positive votes have been garnered, lies with the individual >> serving as release manager. The specifics of the process may vary from >> project to project, but the 'minimum of three +1 votes' rule is universal. >> >> The list of binding voters is available at >> http://felix.apache.org/site/project-management-committe-pmc.html >> >> If the vote is successful, post the result to the dev list - for example: >> >> To: "Felix Developers List" <[email protected]> >> Subject: [RESULT] [VOTE] Release Felix XXX version Y.Z >> >> Hi, >> >> The vote has passed with the following result : >> >> +1 (binding): <<list of names>> >> +1 (non binding): <<list of names>> >> >> I will copy this release to the Felix dist directory and >> promote the artifacts to the central Maven repository. >> If the vote is unsuccessful, you need to fix the issues and restart the >> process - see Canceling the Release. >> If the vote is successful, you need to promote and distribute the release >> - see Promoting the Release. >> >> Canceling the Release >> If the vote fails, or you decide to redo the release: >> >> remove the release tag from Subversion (svn del ...) >> login to https://repository.apache.org using your Apache SVN credentials. >> Click on Staging on the left. Then click on org.apache.felix in the list of >> repositories. In the panel below you should see a closed repository that is >> linked to your username and IP (if it's not yet closed you need to right >> click and select Close). Right click on this repository and select Drop. >> rollback the version in the pom.xml and commit any fixes you need to make >> Promoting the Release >> If the vote passes: >> >> copy the released artifacts to the Felix dist directory (/ >> www.apache.org/dist/felix) on people.apache.org >> delete the old release from the Felix dist directory (it's archived) >> login to https://repository.apache.org with your Apache SVN credentials. >> Click on Staging. Find your closed staging repository, right click on it and >> choose Promote. Select the Releases repository from the drop-down list and >> click Promote. >> next click on Repositories, select the Releases repository and validate >> that your artifacts are all there >> if you're releasing bundles, you can also add them to the Felix Release >> OBR (see Appendix C). >> update the news section on the website >> update the download page on the website to point to the new release. >> For the last two tasks, it's better to give the mirrors some time to >> distribute the uploaded artifacts (one day should be fine). This ensures >> that once the website (news and download page) is updated, people can >> actually download the artifacts. >> >> Update JIRA >> Go to Admin section on the FELIX JIRA and mark the Y.Z version as released >> - create version Y.Z+1, if that hasn't already been done. >> >> Create an Announcement >> To: "Felix Developers List" <[email protected]> >> Subject: [ANN] Felix XXX version Y.Z Released >> >> The Felix team is pleased to announce the release of Felix XXX version Y.Z >> >> <<insert short description of the sub-project>> >> >> http://felix.apache.org/site/apache-felix-XXX.html >> >> This release is available from http://felix.apache.org/site/downloads.cgi and >> Maven: >> >> <dependency> >> <groupId>org.apache.felix</groupId> >> <artifactId>org.apache.felix.XXX</artifactId> >> <version>Y.Z</version> >> </dependency> >> >> Release Notes: >> >> <<insert release notes in text format from JIRA>> >> >> Enjoy! >> >> -The Felix team >> Remember to forward this announcement to [email protected] - try not >> to cross-post (CC:) announcements to both user and dev lists. >> >> Remind Richard about this release when he writes the next board report >> >> Appendix A: create and add your key to >> http://www.apache.org/dist/felix/KEYS >> If you are using a *nix system with a working OpenSSH, GnuPG, and bash you >> can create and add your own key with the following command: >> >> Create a public/private pair key: >> gpg --gen-key >> When gpg asks for e-mail linked the key you MUST USE the <committer>@ >> apache.org one >> When gpg asks for comment linked the key you SHOULD USE "CODE SIGNING KEY" >> >> Add the key to http://www.apache.org/dist/felix/KEYS: type the following >> command replacing the word e-mail with your Apache's one (<committer>@ >> apache.org). >> (gpg --list-sigs e-mail && gpg --export --armor e-mail) > toadd.key >> scp toadd.key people.apache.org: >> ssh people.apache.org "cat toadd.key >> /x1/www/ >> www.apache.org/dist/felix/KEYS" >> You are now DONE, but to see the changes on >> http://www.apache.org/dist/felix/KEYS you must wait 2 hours >> Appendix B: preparing releases on Mac OS X >> When running the mvn release:prepare command on Mac OS X, you might see >> the following error: >> >> [INFO] Executing: svn --non-interactive commit --file >> /tmp/maven-scm-802409492.commit --targets /tmp/maven-scm-18804-targets >> [INFO] Working directory: /homedir/dev/felix/dependencymanager >> [INFO] >> ------------------------------------------------------------------------ >> [ERROR] BUILD FAILURE >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Unable to commit files >> Provider message: >> The svn command failed. >> Command output: >> svn: Commit failed (details follow): >> svn: MKACTIVITY of >> '/repos/asf/!svn/act/4f11ad5d-9161-0410-b4dd-cb727141ea8c': authorization >> failed (https://svn.apache.org) >> This is due to a bug in Subversion on the Mac, as described by Brett >> Porter in his blog. He proposes putting an "svn" script at the head of your >> path to fix the issue. >> >> Appendix C: deploying bundles to the Felix OBR >> If you're releasing bundles, you can also add them to the Felix Release >> OBR. To do this, execute the following command: >> >> mvn clean install \ >> org.apache.felix:maven-bundle-plugin:deploy \ >> -DprefixUrl=http://repo1.maven.org/maven2 \ >> -DremoteOBR=releases.xml \ >> -DaltDeploymentRepository=apache.releases::default::scp:// >> people.apache.org/www/felix.apache.org/obr >> The http://felix.apache.org/obr/releases.xml page is automatically >> updated during the web site synchronization. >> Note: the project building the bundle must use the maven-bundle-plugin and >> use a version superior or equal to 1.4.2. >> >> >> >> Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - >> Bug/feature request >> >> Unsubscribe or edit your notifications preferences >> > > -- Cheers, Stuart
