Nemcio/SCM-Manager
1
0
Fork 0
mirror of https://github.com/scm-manager/scm-manager.git synced 2025-10-26 08:06:09 +01:00
Code Issues Packages Projects Releases Activity

Update release process to new changelog task

Browse Source 
Committed-by: Eduard Heimbuch <eduard.heimbuch@cloudogu.com>
Co-authored-by: René Pfeuffer <rene.pfeuffer@cloudogu.com>
This commit is contained in:
Rene Pfeuffer
2023-01-26 20:00:27 +01:00
committed by SCM-Manager
parent b2a253ea29
commit 8f1f0994d6
2 changed files with 59 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
docs/en/release-process.md
View File

@@ -1,13 +1,36 @@
# How to release SCM-Manager v2 core
# How to release SCM-Manager v2 core (Script)
The most easy way to release the core is to use the release script. This will guide you
through all necessary tasks.
To release a new version of SCM-Manager v2 you have to do the following steps (replace placeholders `<version>` accordingly, eg. with `2.1.0`):
Mind that the script does not care about `support` branches, so if you have one, take
the manual way described below!
Make sure you have no changes you want to keep! The script will clean up everything.
```bash
./release.sh
```
It will
- Clean up your repository with the latest revision of `develop`,
- Update the `CHANGELOG` file,
- Show you the changes it made,
- Ask you whether to proceed or not,
- Create a commit with the changes, and
- Create and push the release branch.
# Manual core release
To release a new version of SCM-Manager v2 "manually", you have to do the following steps
(replace placeholders `<version>` accordingly, eg. with `2.1.0`):
## Check out default branch
Make sure you have no changes you want to keep!
```
```bash
git fetch && git checkout -f origin/develop && git clean -fd && git checkout -B develop
```
@@ -15,7 +38,7 @@ git fetch && git checkout -f origin/develop && git clean -fd && git checkout -B
Check whether there is an integration branch for the previous release or bugfixes not merged into the develop branch. Merge them now.
```
```bash
git merge origin/support/<support branch>
```
@@ -26,10 +49,12 @@ All unreleased changes are stored in the `gradle/changelog` directory.
The changelog can be updated with the `updateChangelog` gradle task.
```bash
export VERSION=<version> \
&& ./gradlew :updateChangelog --release=$VERSION
export VERSION=$(./gradlew :updateChangelog | grep -oP "Using next version \K[0-9.]+")
echo About to release version $VERSION
```
The update changelog task will tell you the next version number.
Now we should manually check if the changelog looks good.
```bash
@@ -42,8 +67,8 @@ If everything looks fine, we can remove the changelog directory.
```bash
git rm -rf gradle/changelog \
&& git checkout -b release/$VERSION \
&& git add CHANGELOG.md \
&& git checkout -b release/$VERSION \
&& git commit -m "Adjust changelog for release $VERSION" \
&& git push origin release/$VERSION
```
@@ -72,7 +97,7 @@ The migration from maven to gradle can easily be done using [this tool](https://
Make sure you have no changes you want to keep!
```
```bash
git fetch && git checkout -f origin/develop && git clean -fd && git checkout -B develop
```
@@ -80,7 +105,7 @@ git fetch && git checkout -f origin/develop && git clean -fd && git checkout -B
Check whether there is an integration branch for the previous release or bugfixes not merged into the develop branch. Merge them now.
```
```bash
git merge origin/support/<support branch>
```
@@ -97,7 +122,10 @@ Check if all plugin dependencies are proper versions and not SNAPSHOT!
## Build, commit and push
```
This step is only needed, when you had to update the version in the prior step.
If the core version has not been increased, this step can be skipped.
```bash
./gradlew build \
&& git add yarn.lock build.gradle package.json \
&& git commit -m "Update to new version of SCM-Manager" \
@@ -113,27 +141,27 @@ All unreleased changes are stored in the `gradle/changelog` directory.
The changelog can be updated with the `updateChangelog` gradle task.
```bash
./gradlew :updateChangelog --release=<version>
export VERSION=$(./gradlew :updateChangelog | grep -oP "Using next version \K[0-9.]+")
echo About to release version $VERSION
```
The task will tell you the next version number.
Now we should manually check if the changelog looks good.
```bash
git diff CHANGELOG.md
```
If everything looks fine, we can remove the changelog directory.
```bash
rm -rf gradle/changelog
```
## Create, commit and push release branch
```
export VERSION=<version> \
This step needs the `VERSION` set in the step above.
```bash
git rm -rf gradle/changelog \
&& git add CHANGELOG.md \
&& git checkout -b release/$VERSION \
&& git commit -am "Prepare release of $VERSION" \
&& git commit -m "Prepare release of $VERSION" \
&& git push origin release/$VERSION
```
@@ -174,3 +202,4 @@ released, yet.
11. Merge this commit into `develop`
If the hotfix has been created for an older release, this process might be somewhat more complicated.

23
release.sh
View File

@@ -9,21 +9,18 @@ git checkout -f origin/develop
git clean -fd
git checkout -B develop
echo Updating changelog
NEW_VERSION=$(./gradlew :updateChangelog | grep -oP "Using next version \K[0-9.]+")
echo These are the current changes
cat ./gradle/changelog/*.yaml
echo Next version number:
read new_version
./gradlew :updateChangelog --release=${new_version}
git diff
echo Proceed? Press Ctrl+c to abort
read x
echo "Release with new version ${NEW_VERSION} (press Ctrl+c to abort)?"
read x
git rm -rf gradle/changelog
git checkout -b release/${new_version}
git add CHANGELOG.md
git commit -m "Adjust changelog for release ${new_version}"
git push origin release/${new_version}
git rm -rf gradle/changelog
git checkout -b release/${NEW_VERSION}
git add CHANGELOG.md
git commit -m "Adjust changelog for release ${NEW_VERSION}"
git push origin release/${NEW_VERSION}