The Continuum source code is stored in a Subversion repository hosted by The Apache Software Foundation. You will need a Subversion client in order to check out the source code. A list of Subversion downloads and third-party clients is available on the Subversion web site.
All
In the Subversion repo, there is a convenience 'all' directory with an svn:externals definition that allows you to check out the trunk, parent POM and site all at once. It will look empty when viewed in your web browser, but checking it out with your Subversion client will bring down all the code.
The trunk of the Subversion repo has version 1.4.x, from which we're publishing milestones. You can find more information about planned features on the Roadmap. If you see something interesting, please join us on the dev list to talk about it!
The Continuum parent POM contains configuration that is common to the entire project. It has a separate, less frequent release cycle than the distribution.
The source for the top-level Continuum website (including this page) is in a separate directory in Subversion. It is published when changes are made, but it is not tagged and "released".
We currentl
y have one active release branch for 1.3.x bug fixes, and several branches for ongoing work. Generally there will be some discussion on the dev list or a JIRA issue opened before a branch is created.
The Continuum source code is stored in a Subversion repository hosted by The Apache Software Foundation. You will need a Subversion client in order to check out the source code. A list of Subversion downloads and third-party clients is available on the Subversion web site.
All
In the Subversion repo, there is a convenience 'all' directory with an svn:externals definition that allows you to check out the trunk, parent POM and site all at once. It will look empty when viewed in your web browser, but checking it out with your Subversion client will bring down all the code.
The trunk of the Subversion repo has version 1.4.x, which are the current GA releases. You can find more information about planned features on the Roadmap. If you see something interesting, please join us on the dev list to talk about it!
The Continuum parent POM contains configuration that is common to the entire project. It has a separate, less frequent release cycle than the distribution.
The source for the top-level Continuum website (including this page) is in a separate directory in Subversion. It is published when changes are made, but it is not tagged and "released".
We do not curren
tly have any active branches for bug fix releases (e.g. 1.3.x). There are several inactive branches for ongoing work. Generally there will be some discussion on the dev list or a JIRA issue opened before a branch is created.
Continuum is versioned X.Y.Z -- Major.Minor.Build. The Major and Minor versions are set at the beginning of a series, after which we use sequential build numbers starting with .0. For example, 1.3.0, 1.3.1, 1.3.2.
Ideally each version is tagged and built exactly once. The Release Manager (RM) has discretion to re-build a version if something goes wrong during the release process, but once a version has been made available for public download, that version number may not be re-used.
During the vote, an additional qualifier is determined. For example: 1.3.0 (M1) or 1.3.7 (GA). Respectively, these mean Milestone 1 and General Availability. Qualifiers such as Alpha and Beta are also acceptable, as is RC (Release Candidate).
If the vote does not pass, the qualifier may be reused. For example, if 1.3.0 was meant to be Milestone 1 but does not
get approved, 1.3.1 can become M1.
When releases are announced to the community, the additional qualifier is used in addition to the version number. For example: [ANN] Continuum 1.3.3 (Milestone 2) Release or [ANN] Continuum 1.3.6 (GA) Release
A qualifier can be changed by calling a new vote. If we get to 1.3.8 (M5) and decide that it has no problems and there's nothing else we want to add, we can simply re-label it GA and update the website.
New features may be added to 1.3.x releases until we reach GA, at which point only minor changes should be made.
If the vote does not pass, the binaries should be removed from the download area, and the version should be labeled "test build" on the release notes page.
Continuum Release Preparation
Post to the dev list a few days before you plan to do a Continuum relea
se
Check for SNAPSHOT dependencies, including the Continuum parent POM
Check trunk is building correctly (including Selenium tests) by running:
mvn clean install -Pintegration
<
li>Execute mvn release:prepare (check that it has been properly tagged. The tag name must be continuum-[VERSION])
Then execute mvn release:perform
Copy the release artifacts from the Archiva repository to the Continuum distribution testing area. To do this, obtain the copy-release.sh script and run it locally against ~/.m2/repository, or anywhere against https://archiva-repository.apache.org/archiva/repository/continuum-releases/
Stage the site mvn -Ptag site-deploy from the continuum-docs module of the release tag or target/checkout directory
Call for a vote in the dev list and wait for 72 hours for the vote results. 3 binding v
otes from PMC members are necessary for the release to be finalized. Example.
After the vote has passed, copy the sources and binaries to the production Continuum distribution area
Remove versions that no longer need to be downloaded from mirrors. To do this, obtain the remove-release.sh script and run it
./remove-release.sh 1.4.1
To sync the JARs to the central repository, execute:
mvn stage:copy -Dsource="[STAGE_REPO_URL]" \
+
Continuum Release Guidelines
Continuum is versioned X.Y.Z -- Major.Minor.Build. The Major and Minor versions are set at the beginning of a series, after which we use sequential build numbers starting with .0. For example, 1.3.0, 1.3.1, 1.3.2.
Ideally each version is tagged and built exactly once. The Release Manager (RM) has discretion to re-build a version if something goes wrong during the release process, but once a version has been made available for public download, that version number may not be re-used.
During the vote, an additional qualifier is determined. For example: 1.3.0 (M1) or 1.3.7 (GA). Respectively, these mean Milestone 1 and General Availability. Qualifiers such as Alpha and Beta are also acceptable, as is RC (Release Candidate).
If the vote does not pass, the qualifier may be reused. For example, if 1.3.0 was meant to be Milestone 1 but does not
get approved, 1.3.1 can become M1.
When releases are announced to the community, the additional qualifier is used in addition to the version number. For example: [ANN] Continuum 1.3.3 (Milestone 2) Release or [ANN] Continuum 1.3.6 (GA) Release
A qualifier can be changed by calling a new vote. If we get to 1.3.8 (M5) and decide that it has no problems and there's nothing else we want to add, we can simply re-label it GA and update the website.
New features may be added to 1.3.x releases until we reach GA, at which point only minor changes should be made.
If the vote does not pass, the binaries should be removed from the download area, and the version should be labeled "test build" on the release notes page.
Continuum Release Preparation
Post to the dev list a few days before you plan to do a Continuum relea
se
Check for SNAPSHOT dependencies, including the Continuum parent POM
Check trunk is building correctly (including Selenium tests) by running:
mvn clean install -Pintegration
<
li>Execute mvn release:prepare (check that it has been properly tagged. The tag name must be continuum-[VERSION])
Then execute mvn release:perform
Copy the release artifacts from the Archiva repository to the Continuum distribution testing area. To do this, obtain the copy-release.sh script and run it locally against ~/.m2/repository, or anywhere against https://archiva-repository.apache.org/archiva/repository/continuum-releases/
Stage the site mvn -Ptag site-deploy from the continuum-docs module of the release tag or target/checkout directory
Call for a vote in the dev list and wait for 72 hours for the vote results. 3 binding v
otes from PMC members are necessary for the release to be finalized. Example.
After the vote has passed, remove versions that no longer need to be downloaded from mirrors. To do this, obtain the remove-release.sh script and run it
./remove-release.sh 1.4.0
Copy the sources and binaries to the production Continuum distribution area (only needs to be done once for all staged releases)
Update the Continuum site at https://svn.apache.org/repos/asf/continuum/site/ with the versions and release notes URL and run mvn site-deploy. Below is the list of pages that you need to update:
src/site/xdoc/index.xml
src/site/apt/known-issues.apt
src/site/apt/download.apt
src/site/apt/changelog.apt
Publish the reference docs (mvn site site:stage scm-publish:publish-scm from the release tag or previous target/checkout directory.
Update JIRA to indicate the version is release
d
Send out an announcement of the release to users@continuum.apache.org, and announce@apache.org (for GA releases). This must be sent from your @apache.org address.
Update the Continuum site at https://svn.apache.org/repos/asf/continuum/site/ with the versions and release notes URL and run mvn site-deploy. This can be usually be addressed by changing <gaVersion>/<gaDate> or <betaVersion>/<betaDate> in pom.xml.
Publish the reference docs (mvn site site:stage scm-publish:publish-scm from the release tag or previous target/checkout directory.
Update JIRA to indicate the version is released
Send out an announcement of the release to users@co
ntinuum.apache.org, and announce@apache.org (for GA releases). This must be sent from your @apache.org address.
Remove versions that no longer need to be downloaded from mirrors, using the remove-release.sh script referred to above:
./remove-release.sh parent-5
Update the parent POM version in Continuum at https://svn.apache.org/repos/asf/continuum/trunk (or in the branch), in the site at https://svn.apache.org/repos/asf/continuum/site, and the skin at https://svn.apache.org/repos/asf/continuum/skin/trunk to change the parent POM version to the continuum-parent version that has just been released
Commit the changes made
Releasing the Site Skin
Check out the source from https://svn.apache.org/repos/asf/continuum/skin/trunk
mvn release:p
repare (verify that it has been properly tagged)
mvn release:perform (verify that it has been deployed correctly in the staging repo)
Copy the source release to the distribution area, using the copy-release.sh script referred to above:
./copy-release.sh skin-1.0
Conduct a vote (or do it in conjunction with a Continuum release)
After the vote has passed, copy the sources to the production Continuum distribution area
Remove versions that no longer need to be downloaded from mirrors, using the remove-release.sh script referr
ed to above:
./remove-release.sh skin-1.0
Update the site.xml in Continuum at https://svn.apache.org/repos/asf/continuum/trunk and in the site at https://svn.apache.org/repos/asf/continuum/site
Update the parent POM version in Continuum at https://svn.apache.org/repos/asf/continuum/trunk (or in the branch), in the site at https://svn.apache.org/repos/asf/continuum/site, and the skin at https://svn.apache.org/repos/asf/continuum/skin/trunk to change the parent POM version to the continuum-parent version that has just been released
Commit the changes made
Releasing the Site Skin
Check out the source from https://svn.apache.org/repos/asf/continuum/skin/trunk
mvn release:prepare (verify that it has been properly tagged)
mvn release:perform (verify that it has been deployed correctly in the staging repo)
Copy the source release to the distribution area, using the copy-release.sh script referred to above:
./copy-release.sh skin-1.0
Conduct a vote (or do it in conjunction with a Continuum release)
After the vote has passed, remove versions that no longer need to be downloaded from mirrors, using the remove-release.sh script referred to above:
./remove-release.sh skin-1.0
Copy the sources to the production Continuum distribution area (only needs to be done once for all staged releases)
Update the site.xml in Continuum at https://svn.apache.org/repos/asf/continuum/trunk and in the site at https://svn.apache.org/repos/asf/continuum/site
Commit the changes made
Modified: continuum/site-publish/distribution-management.html
URL: http://svn.apache.org/viewvc/continuum/site-publish/distribution-management.html?rev=1429667&r1=1429666&r2=1429667&view=diff
==============================================================================
--- continuum/site-publish/distribution-management.html (original)
+++ continuum/site-publish/distribution-management.html Mon Jan 7 03:58:08 2013
@@ -68,7 +68,7 @@ pageTracker._trackPageview();
- Last Published: 04 Jan 2013
+ Last Published: 07 Jan 2013
Apache Continuum is an enterprise-ready continuous integration server with features such as automated builds, release management, role-based security, and integration with popular build tools and source control management systems. Whether you have a centralized build team or want to put control of releases in the hands of developers, Continuum can help you improve quality and maintain a consistent build environment.
We recommend that you verify the integrity of the downloaded files using the PGP signatures and MD5 checksums.
The PGP signatures can be verified using PGP or GPG. First download the KEYS as well as the asc signature file for the particular distribution. Make sure you get these files from the main distribution directory, rather than from a mirror. Then verify the signatures using
You can also verify the MD5 signature on the files. A Unix program called md5 or md5sum is included in many Unix distributions. It is also available as part of GNU Coreutils. Windows users can get binary md5 programs from Fourmilab, PC-Tools or SlavaSoft.
+
+
+
+
Download Apache Continuum
+
+
+ Apache Continuum is an enterprise-ready continuous integration server with
+ features such as automated builds, release management, role-based security,
+ and integration with popular build tools and source control management
+ systems. Whether you have a centralized build team or want to put control of
+ releases in the hands of developers, Continuum can help you improve quality
+ and maintain a consistent build environment.
+
+
+
Mirror Selection
+
+
+[if-any logo]
+
+
+
+[end]
+ The currently selected mirror is [preferred]. If you encounter a
+ problem with this mirror, please select another mirror. If all mirrors are
+ failing, there are backup mirrors (at the end of the mirrors list)
+ that should be available.
+
+ We recommend that you verify the integrity of the downloaded files using the
+ PGP signatures and MD5 checksums.
+
+
+
+ The PGP signatures can be verified using PGP or GPG. First download the KEYS as well as the
+ asc signature file for the particular distribution. Make sure you get these
+ files from the main
+ distribution directory, rather than from a mirror. Then verify the
+ signatures using
+
+ You can also verify the MD5 signature on the files. A Unix program called
+ md5 or md5sum is included in many Unix distributions. It is also available
+ as part of GNU
+ Coreutils. Windows users can get binary md5 programs from Fourmilab, PC-Tools or SlavaSoft.
+
+
+
+
+
Modified: continuum/site-publish/error-states.html
URL: http://svn.apache.org/viewvc/continuum/site-publish/error-states.html?rev=1429667&r1=1429666&r2=1429667&view=diff
==============================================================================
--- continuum/site-publish/error-states.html (original)
+++ continuum/site-publish/error-states.html Mon Jan 7 03:58:08 2013
@@ -69,7 +69,7 @@ pageTracker._trackPageview();
- Last Published: 04 Jan 2013
+ Last Published: 07 Jan 2013