opendev/gerrit
Code Issues Proposed changes

Adapt Release Docs

Browse Source 
* Remove section about subprojects as they are released independently
* Lowercase the usage of 'rc' as branches and artifacts are all lower case as well

Change-Id: Id1552ab33c9a5af8e16ecfec5578e50cd3c742ed
This commit is contained in:
Patrick Hiesel
2017-04-13 10:08:53 +02:00
parent 4185224942
commit 9d165c501c
1 changed files with 8 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
Documentation/dev-release.txt
View File

@@ -16,8 +16,8 @@ tasks.
== Gerrit Release Type == Gerrit Release Type
Here are some guidelines on release approaches depending on the Here are some guidelines on release approaches depending on the
type of release you want to make (`stable-fix`, `stable`, `RC0`, type of release you want to make (`stable-fix`, `stable`, `rc0`,
`RC1`...). `rc1`...).
[[stable]] [[stable]]
=== Stable === Stable
@@ -27,19 +27,19 @@ need to undergo some stabilization before releasing the final release.
* Propose the release with any plans/objectives to the mailing list * Propose the release with any plans/objectives to the mailing list
* Create a Gerrit `RC0` * Create a Gerrit `rc0`
* If needed create a Gerrit `RC1` * If needed create a Gerrit `rc1`
[NOTE] [NOTE]
You may let in a few features to this release You may let in a few features to this release
* If needed create a Gerrit `RC2` * If needed create a Gerrit `rc2`
[NOTE] [NOTE]
There should be no new features in this release, only bug fixes There should be no new features in this release, only bug fixes
* Finally create the `stable` release (no `RC`) * Finally create the `stable` release (no `rc`)
=== Stable-Fix === Stable-Fix
@@ -75,7 +75,6 @@ the `gerrit-security-fixes` project be taken over into the public
To create a Gerrit release the following steps have to be done: To create a Gerrit release the following steps have to be done:
. link:#subproject[Release Subprojects]
. link:#build-gerrit[Build the Gerrit Release] . link:#build-gerrit[Build the Gerrit Release]
. link:#publish-gerrit[Publish the Gerrit Release] . link:#publish-gerrit[Publish the Gerrit Release]
.. link:#publish-to-maven-central[Publish the Gerrit artifacts to Maven Central] .. link:#publish-to-maven-central[Publish the Gerrit artifacts to Maven Central]
@@ -90,34 +89,10 @@ To create a Gerrit release the following steps have to be done:
. link:#merge-stable[Merge `stable` into `master`] . link:#merge-stable[Merge `stable` into `master`]
[[subproject]]
=== Release Subprojects
The subprojects to be released are:
* `gwtjsonrpc`
* `gwtorm`
* `prolog-cafe`
For each subproject do:
* Check the dependency to the Subproject in the Gerrit parent `pom.xml`:
+
If a `SNAPSHOT` version of the subproject is referenced the subproject
needs to be released so that Gerrit can reference a released version of
the subproject.
* link:dev-release-subproject.html#make-snapshot[Make a snapshot and test it]
* link:dev-release-subproject.html#prepare-release[Prepare the Release]
* link:dev-release-subproject.html#publish-release[Publish the Release]
* Update the `artifact`, `sha1`, and `src_sha1` values in the `maven_jar`
for the Subproject in `WORKSPACE` to the released version.
[[update-versions]] [[update-versions]]
=== Update Versions and Create Release Tag === Update Versions and Create Release Tag
Before doing the release build, the `GERRIT_VERSION` in the `VERSION` Before doing the release build, the `GERRIT_VERSION` in the `version.bzl`
file must be updated, e.g. change it from `2.5-SNAPSHOT` to `2.5`. file must be updated, e.g. change it from `2.5-SNAPSHOT` to `2.5`.
In addition the version must be updated in a number of pom.xml files. In addition the version must be updated in a number of pom.xml files.
@@ -383,7 +358,7 @@ for the next release.
Use the `version` tool to set the version in the `version.bzl` file: Use the `version` tool to set the version in the `version.bzl` file:
---- ----
./tools/version.py 2.11-SNAPSHOT ./tools/version.py 2.6-SNAPSHOT
---- ----
Verify that the changes made by the tool are sane, then commit them, push Verify that the changes made by the tool are sane, then commit them, push