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;">...
<server>
<id>apache.releases.https</id>
@@ -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 .....
