Author: billie
Date: Mon Nov 14 20:19:35 2011
New Revision: 1201874
URL: http://svn.apache.org/viewvc?rev=1201874&view=rev
Log:
proofread release page
Modified:
incubator/accumulo/site/trunk/content/accumulo/governance/releasing.mdtext
Modified: incubator/accumulo/site/trunk/content/accumulo/governance/releasing.mdtext
URL: http://svn.apache.org/viewvc/incubator/accumulo/site/trunk/content/accumulo/governance/releasing.mdtext?rev=1201874&r1=1201873&r2=1201874&view=diff
==============================================================================
--- incubator/accumulo/site/trunk/content/accumulo/governance/releasing.mdtext (original)
+++ incubator/accumulo/site/trunk/content/accumulo/governance/releasing.mdtext Mon Nov 14
20:19:35 2011
@@ -16,21 +16,21 @@ Notice: Licensed to the Apache Softwa
specific language governing permissions and limitations
under the License.
-Accumulo works on a very simple cycle of major releases with the minor releases when needed.
The intent is for all major features to be implemented in a major release, with only bug fixes
and minor features being included in minor releases. API changes should intend to only be
made on major releases, with continued support of previous API for at least one major revision.
This will give user code a major revision to convert from the old API to the new API.
+Accumulo works on a very simple cycle of major releases with the minor releases when needed.
The intent is for all major features to be implemented in a major release, with only bug fixes
and minor features being included in minor releases. API changes should only be made on major
releases, with continued support of the previous API for at least one major revision. This
will give user code a major revision to convert from the old API to the new API.
Note: There will be times where API compatibility cannot be maintained, which we understand.
However, this should only be considered when there is NO other option.
## Major Release
- 1. Vote to start the major release process- this should be in consensus with the community
and should be discussed on the accumulo-dev mailing list before the next steps take place.
The majority of the committers must +1 the vote and all -1s need to be discussed.
+ 1. Vote to start the major release process. This should be in consensus with the community
and should be discussed on the accumulo-dev mailing list before the next steps take place.
The majority of the committers must +1 the vote and all -1s need to be discussed.
- There is not a strict time limit between major releases, but some consideration should
be made because we don't want to give our early adopters version fatigue.
- - This will be the feature freeze for the version- Any features considered after this
call need a very strong reason for implementation, which can be discussed via mailing list.
- - Create a JIRA version for the proceeding release number- this is so we can begin the
process of noting which features are bound for the current trunk vs. a future version.
- - Handle all JIRA tickets assigned for the current major release version- all tickets who's
version is changed should have an explanation of why they are not to be handled in the current
release.
- - Once all JIRA tickets against the codebase (documentation tickets do not count) are resolved/redirected,
the code will be branched in SVN.
+ - This will be the feature freeze for the version. Any features considered after this
call need a very strong reason for implementation, which can be discussed via mailing list.
+ - Create a JIRA version for the proceeding release number. This is so we can begin the
process of noting which features are bound for the current trunk vs. a future version.
+ - Handle all JIRA tickets assigned for the current major release version. Any ticket whose
version is changed should have an explanation of why it is not to be handled in the current
release.
+ - Once all JIRA tickets against the codebase (except documentation tickets) are resolved/redirected,
the code will be branched in SVN.
- While there is currently a new trunk for the next release, it is highly discouraged
to begin committing new features to it because this is when the current release is being tested.
Any major bugs found will have to be patched in both versions and we want to make the process
as seamless as possible.
- - New trunk needs to have it's version information updated.
+ - The new trunk needs to have its version information updated.
- Wrap up any standing documentation endeavors, whether or not there are tickets for them.
- Test the branch as per our testing criteria.
- Once testing is deemed successful and release documentation is complete, move on to Releasing.
@@ -38,25 +38,25 @@ Note: There will be times where API comp
## Minor Release
1. Upon detection and/or resolution of a bug, discussion needs to be made on the accumulo-dev
list to determine if the community thinks the bug is critical or if there have been sufficient
minor bug fixes to warrant a minor release.
- - Make any necessary documentation changes, included change log.
+ - Make any necessary documentation changes, including a change log.
- Test the now updated branch as per our testing criteria.
- Once testing is deemed successful and documentation is complete, move on to Releasing.
## Testing
- 1. All JUnit tests must pass- this should be a requirement of any patch so it should never
be an issue of the codebase.
+ 1. All JUnit tests must pass. This should be a requirement of any patch so it should never
be an issue of the codebase.
- All functional tests must complete successfully.
- - 2 24 hour periods of the randomwalk LongClean test with and without agitation need to
be run successfully - this should be on a cluster.
- - 2 24 hour periods of continuous ingest with and without agitation needs to be validated
successfully - this should be on a cluster.
- - 2 72 hour periods of continuous ingest with and without agitation. No validation is necessary
but the cluster should be checked to ensure it's still functional - this should be on a cluster.
+ - Two 24-hour periods of the randomwalk LongClean test with and without agitation need
to be run successfully on a cluster.
+ - Two 24-hour periods of continuous ingest with and without agitation need to be validated
successfully on a cluster.
+ - Two 72-hour periods of continuous ingest with and without agitation on a cluster. No
validation is necessary but the cluster should be checked to ensure it is still functional.
## Releasing
1. Tag the tested branch. It should:
- - Have it's version set to note it is RC1.
- - Be fully built, including tar.gz of the entire project as well as the documentation.
- - PGP Signatures of the tarball must be signed to a separate file and made available in
the public_html folder in people.apache.org, along with the tarball and MD5 and SHA512 checksums.
- - A vote must be made in accumulo-dev, lazy consensus is not sufficient for a release.
All checksums and signatures need to be verified before any voter can +1 it. Voting shall
last 72 hours.
+ - Have its version set to note it is RC1.
+ - Be fully built, including a tar.gz of the entire project as well as the documentation.
+ - PGP Signatures of the tarball must be signed to a separate file and made available in
the public_html folder of the user creating the release on people.apache.org, along with the
tarball and MD5 and SHA512 checksums.
+ - A vote must be made on accumulo-dev; lazy consensus is not sufficient for a release.
All checksums and signatures need to be verified before any voter can +1 it. Voting shall
last 72 hours.
- Upon successful vote, the release candidate can be brought to the incubator mailing list
for approval.
- Upon success from the incubator list, the new releases can be retagged to remove the
RC status and released on the Accumulo webpage.
- If at any time the tag needs to be remade due to any sort of error, it should be incremented
to the next release candidate number.
\ No newline at end of file