Release script

[davidgraeff]

People agreed on having a release script.
The script goes through all commits since the last git tag and computes the next semver compliant version and creates a new tag for the current "develop" head. It will also trigger a new web-page build.

This issue is for discussing the script, where to locate it, how to trigger it and so on.

[Thalhammer]

A simple way would be to run a script on some kind of server, which gets triggered by a github webhook. The script itself should be kept in some repo on this organisation.
Another way would be some kind of cron job on a server.
Both of these are kind of problematic if the person hosting the scripts for some reason decides to just discontinue working, as it would take at least a short time until everything was set up again by a different user. Maybe a public CI service is better suited, but this will be managed by a single person as well. The best solution would be a script hosted by github but I don't of a way to do so (Gitlab would allow for this but thats out of scope).

[davidgraeff]

The current idea is to use travis and trigger the build with a commit having a "[release]" text in the commit message.

[timpur]

My only remark would be, just like you have BREAKING: in the PR can we have the same for RELEASE: ? I also assume this wold be for the PR from dev to master

Edit: Also can we make this release step go through more approval, like at lest 4 approvers ? I think its important that we get it right the first time and that means we all agree on a release.

[davidgraeff]

Idea for a release script:

#!/bin/bash
# Get latest tag and all commits since the latest tag
latestversion=$(git describe --tags $(git rev-list --tags --max-count=1)|sed 's/v\([0-9\.]*\).*/\1/')
sincelast=$(git log --oneline $(git describe --tags --abbrev=0 @^)..@)

# Determine if it is a major, minor or fix increment
a=( ${latestversion//./ } )
case "$sincelast" in
    *BREAKING\:*) ((a[0]++))   ;;
    *feature\:*)  ((a[1]++))  ;;
    *)            ((a[2]++)) ;;
esac

# Read convention file and replace placeholder with version and release date
latestversion=${a[0]}.${a[1]}.${a[2]}
convention=`cat convention.md`
now=$(date +"%d. %b %Y")
sed -i "s/<!--VERSION-->x\.x\.x<!--VERSION-->/$latestversion/" convention.md
sed -i "s/<!--DATE-->01\. Jan 2000<!--DATE-->/$now/" convention.md

# Commit convention file with version and release date
git add convention.md
git commit -m "Release $latestversion"
git tag "v$latestversion"

# Reset to placeholder variant, commit
echo "$convention" > convention.md
git add convention.md
git commit -m "Start new development cycle"

# TODO: push 

echo $latestversion

[Thalhammer]

Instead of reseting the commited version number by a second commit, howabout first changing to a branch and commit there, never inserting the version number into the document in master ? This would keep the history a lot cleaner

[davidgraeff]

Marvin has done it in even another way, by push forcing a single commit with the latest version to master and tagging that.

Personally I like it how it is supposed to be done: Tags are only tagging a point in time of the entire linear history of the project. If you diverge from your tag, you end up with a tree branch like structure instead of a linear history.

I don't think we need "master" and "develop" with my approach actually.

[Thalhammer]

No the history would still be linear, as further development would not be based on the new branch but on the commit just before the script ran.

c1
|
c2 --- c3/tag
|
c4
|
c5 --- c6/tag
|
....

[davidgraeff]

Hm. I have to think about it. This is of course not a linear history, there are "dangling" commits, only kept alive by the tag. Might work by tagging, going back one commit with "reset --hard" and then force pushing including tags.
It is at least not easy with git, for a reason I guess.

[davidgraeff]

We are going with a manual release for now. I'm closing this issue.