felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart McCulloch <mccu...@gmail.com>
Subject Re: [CONF] Apache Felix: Release Management (Nexus) (page edited)
Date Thu, 23 Apr 2009 04:52:15 GMT
2009/4/23 Clement Escoffier <clement.escoffier@gmail.com>

> 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, confluence@apache.org 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" <dev@felix.apache.org>
>> 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
>> 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" <dev@felix.apache.org>
>> 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" <dev@felix.apache.org>
>> 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 users@felix.apache.org - 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]
>> ------------------------------------------------------------------------
>> [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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message