cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r959911 - in /websites/production/cxf/content: cache/main.pageCache release-management.html
Date Tue, 28 Jul 2015 16:47:37 GMT
Author: buildbot
Date: Tue Jul 28 16:47:36 2015
New Revision: 959911

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/main.pageCache
    websites/production/cxf/content/release-management.html

Modified: websites/production/cxf/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/release-management.html
==============================================================================
--- websites/production/cxf/content/release-management.html (original)
+++ websites/production/cxf/content/release-management.html Tue Jul 28 16:47:36 2015
@@ -108,7 +108,7 @@ Apache CXF -- Release Management
          <td height="100%">
            <!-- Content -->
            <div class="wiki-content">
-<div id="ConfluenceContent"><h2 id="ReleaseManagement-Deployingsnapshots">Deploying
snapshots</h2><p>Snapshots are automatically deployed every night to the Nexus
snapshot repository at <a shape="rect" class="external-link" href="https://repository.apache.org/content/groups/snapshots-group/">https://repository.apache.org/content/groups/snapshots-group/</a>
. There is no need to manually deploy snapshots anymore.</p><h2 id="ReleaseManagement-Maintainingafixesbranch">Maintaining
a fixes branch</h2><p>dkulp: I'm adding this section to document what worked for
ME when maintaining the 2.7.x-fixes branch for the 2.7.x releases. Each Release Manager may
have their own style or tools or whatever. This is not a "set in stone" type thing.</p><p>Basically,
almost all development and fixes and such are usually done by the various developers right
on master. Thus, the main job of the fixes branch maintainer is to triage the commits on master
and merge pure fixes to the fixes branches, resolve co
 nflicts, run the tests, and periodically deploy snapshots. For the most part, when things
go well, it doesn't take too much time or effort. An hour or two every couple days is about
it.</p><p>To set up, you'll want to:</p><ol><li>use git branch
to make a branch.</li><li>On the branch, create a .gitmergeinfo file with a single
line of "origin/master" to say the branch will be merging from there.</li></ol><p><span
style="background-color: transparent;line-height: 1.4285715;">In trunk/bin, there is a
DoMerges.java program that assists in the merging. If the branch is setup with .gitmergeinfo,
if you run it from the root directory of the checkout, it will prompt for every commit on
master to see if you want to "Merge" it, "Block" it, or "Ignore" it. It displays the commit
log first so you can see what was involved. You can also check the </span><a shape="rect"
class="external-link" href="http://www.nabble.com/cxf-commits-f23851.html" style="background-color:
transparent;line-height: 1.4
 285715;" rel="nofollow">cxf-commits</a><span style="background-color: transparent;line-height:
1.4285715;"> archive to see the full details of the commit to help decide what action to
take. If you select "Merge", it will merge the change and then prompt before committing. That
will allow you to look at the merge and resolve any conflicts. (or even revert it if you didn't
mean to hit Merge)</span></p><h2 id="ReleaseManagement-Performingarelease">Performing
a release</h2><p>The first step is to update the release_notes.txt in the distribution/src/main/release.
This file's JIRA list of solved Bugs, Improvements, etc. can be obtained from the <a shape="rect"
class="external-link" href="https://issues.apache.org/jira/browse/CXF#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel">"Road
Map" JIRA tab</a>, selecting the desired version's Release Notes, and then the Configure
Release Notes button (choose Text output).</p><div class="confluence-information-macro
confluence-i
 nformation-macro-note"><span class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>Don't manually update the POM versions
from X.Y.Z-SNAPSHOT to X.Y.Z, the Maven Release Plugin commands below will automatically take
care of that. Also, prior to performing the release you'll need to have your Apache LDAP information
configured in your Maven settings.xml file:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<div id="ConfluenceContent"><h2 id="ReleaseManagement-Deployingsnapshots">Deploying
snapshots</h2><p>Snapshots are automatically deployed every night to the Nexus
snapshot repository at <a shape="rect" class="external-link" href="https://repository.apache.org/content/groups/snapshots-group/">https://repository.apache.org/content/groups/snapshots-group/</a>
. There is no need to manually deploy snapshots anymore.</p><h2 id="ReleaseManagement-Maintainingafixesbranch">Maintaining
a fixes branch</h2><p>dkulp: I'm adding this section to document what worked for
ME when maintaining the 2.7.x-fixes branch for the 2.7.x releases. Each Release Manager may
have their own style or tools or whatever. This is not a "set in stone" type thing.</p><p>Basically,
almost all development and fixes and such are usually done by the various developers right
on master. Thus, the main job of the fixes branch maintainer is to triage the commits on master
and merge pure fixes to the fixes branches, resolve co
 nflicts, run the tests, and periodically deploy snapshots. For the most part, when things
go well, it doesn't take too much time or effort. An hour or two every couple days is about
it.</p><p>To set up, you'll want to:</p><ol><li>use git branch
to make a branch.</li><li>On the branch, create a .gitmergeinfo file with a single
line of "origin/master" to say the branch will be merging from there.</li></ol><p><span
style="background-color: transparent;line-height: 1.4285715;">In trunk/bin, there is a
DoMerges.java program that assists in the merging. If the branch is setup with .gitmergeinfo,
if you run it from the root directory of the checkout, it will prompt for every commit on
master to see if you want to "Merge" it, "Block" it, or "Ignore" it. It displays the commit
log first so you can see what was involved. You can also check the </span> <a shape="rect"
class="external-link" href="http://www.nabble.com/cxf-commits-f23851.html" style="background-color:
transparent;line-height: 1.
 4285715;" rel="nofollow">cxf-commits</a> <span style="background-color: transparent;line-height:
1.4285715;"> archive to see the full details of the commit to help decide what action to
take. If you select "Merge", it will merge the change and then prompt before committing. That
will allow you to look at the merge and resolve any conflicts. (or even revert it if you didn't
mean to hit Merge)</span></p><h2 id="ReleaseManagement-Performingarelease">Performing
a release</h2><p>The first step is to update the release_notes.txt in the distribution/src/main/release.
This file's JIRA list of solved Bugs, Improvements, etc. can be obtained from the <a shape="rect"
class="external-link" href="https://issues.apache.org/jira/browse/CXF#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel">"Road
Map" JIRA tab</a>, selecting the desired version's Release Notes, and then the Configure
Release Notes button (choose Text output).</p><div class="confluence-information-macro
confluence
 -information-macro-note"><span class="aui-icon aui-icon-small aui-iconfont-warning
confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Don't
manually update the POM versions from X.Y.Z-SNAPSHOT to X.Y.Z, the Maven Release Plugin commands
below will automatically take care of that. Also, prior to performing the release you'll need
to have your Apache LDAP information configured in your Maven settings.xml file:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">...
 &lt;server&gt;                                                                
    &lt;id&gt;apache.releases.https&lt;/id&gt;
@@ -121,7 +121,7 @@ Apache CXF -- Release Management
 <pre>mvn release:prepare -Peverything,jaxws22
 mvn release:perform -Peverything,jaxws22
 </pre>
-</div></div><p>The above commands tag the release, update the poms versions,
etc., then build it (off the tag), gpg sign and deploy everything (including source jars and
javadoc jars) to the <a shape="rect" class="external-link" href="https://repository.apache.org">Nexus
repository location</a>. When the build is done staging, you next need to login to the
Nexus repository and "close" the staging area (click on Staging Repositories in the left-side
menu, select the repo you just uploaded and then select the close button.) Closing is very
important. After the staging area is closed, note the URL for the staging area as you will
need that for the vote.</p><p>At this point, everything "pre-vote" is done. Call
the vote.</p><h2 id="ReleaseManagement-Releasingtheartifacts">Releasing the artifacts</h2><ul><li>Maven
artifacts - After the vote passes, you'll need to promote that staging repository to the main
location. Login to <a shape="rect" class="external-link" href="https://repository.a
 pache.org">Nexus repository location</a> to do that as well, find the staging repository
and click the Release button.</li></ul><ul><li><p>Distributions
- You will need to commit the distributions into the special svn distribution area: <a
shape="rect" class="external-link" href="https://dist.apache.org/repos/dist/release/cxf">https://dist.apache.org/repos/dist/release/cxf</a><br
clear="none"> after you commit they will be live on dist.apache.org fairly quickly, but
it will still take time for the mirrors to get copies. It's likely easier to make the directory
via an svn command, check out just that directory, and then add the files. The dist area is
rather large (400MB or so) so checking out the entire thing may be slow.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+</div></div><div class="confluence-information-macro confluence-information-macro-warning"><span
class="aui-icon aui-icon-small aui-iconfont-error confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>If you are performing the release on
a Mac, it is advisable to add -DpushChanges=false to the "release:prepare" step above. The
version of git that Apple ships with some versions of OSX has problems pushing the changes
in quick succession from the release plugin and can become corrupt. Having the release plugin
NOT push the changes and then running "git push -tags origin master" works around that problem.</p></div></div><p>The
above commands tag the release, update the poms versions, etc., then build it (off the tag),
gpg sign and deploy everything (including source jars and javadoc jars) to the <a shape="rect"
class="external-link" href="https://repository.apache.org">Nexus repository location</a>.
When the build is done staging, you next need to 
 login to the Nexus repository and "close" the staging area (click on Staging Repositories
in the left-side menu, select the repo you just uploaded and then select the close button.)
Closing is very important. After the staging area is closed, note the URL for the staging
area as you will need that for the vote.</p><p>At this point, everything "pre-vote"
is done. Call the vote.</p><h2 id="ReleaseManagement-Releasingtheartifacts">Releasing
the artifacts</h2><ul><li>Maven artifacts - After the vote passes, you'll
need to promote that staging repository to the main location. Login to <a shape="rect"
class="external-link" href="https://repository.apache.org">Nexus repository location</a>
to do that as well, find the staging repository and click the Release button.</li></ul><ul><li><p>Distributions
- You will need to commit the distributions into the special svn distribution area: <a
shape="rect" class="external-link" href="https://dist.apache.org/repos/dist/release/cxf">https://dist.apac
 he.org/repos/dist/release/cxf</a> <br clear="none"> after you commit they will
be live on dist.apache.org fairly quickly, but it will still take time for the mirrors to
get copies. It's likely easier to make the directory via an svn command, check out just that
directory, and then add the files. The dist area is rather large (400MB or so) so checking
out the entire thing may be slow.</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">svn
mkdir https://dist.apache.org/repos/dist/release/cxf/2.6.3
 svn checkout https://dist.apache.org/repos/dist/release/cxf/2.6.3
 ....  add files to 2.6.3 .....



Mime
View raw message