You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Clement Escoffier <cl...@gmail.com> on 2009/04/22 19:47:02 UTC
Re: [CONF] Apache Felix: Release Management (Nexus) (page edited)
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.
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" <de...@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 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" <de...@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" <de...@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]
> ------------------------------------------------------------------------
> [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
Re: [CONF] Apache Felix: Release Management (Nexus) (page edited)
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/4/23 Clement Escoffier <cl...@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" <de...@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
>> 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" <de...@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" <de...@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]
>> ------------------------------------------------------------------------
>> [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