2017-10-03 08:54:41 +00:00
|
|
|
#!/bin/sh
|
|
|
|
VERSION=$1
|
|
|
|
REL=$2
|
|
|
|
|
|
|
|
if [ "z$REL" = "z" ]; then
|
|
|
|
echo "No REL value specified, defaulting to 'patch' release"
|
2018-08-30 10:42:37 +00:00
|
|
|
REL="patch"
|
2017-10-03 08:54:41 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
BUMPVER=`command -v bumpversion`
|
|
|
|
|
|
|
|
NEW_VER=`bumpversion --list --current-version $VERSION $REL --allow-dirty | awk -F '=' '{ print $2 }'`
|
|
|
|
LIBVERS=`git grep -n LIBVERSION | grep '=' | grep am | grep -v LDFLAGS`
|
osmo-release.sh: Always generate entire commit changelog
Before this commit, for library projects (containing LIBVERSION in some
Makefile), the entire commit list was not stored into the changelog, but
only a few lines from TODO-RELEASE files.
This is a bad approach for several reasons. First, because that file was
only aimed at containing API/ABI breaks, and not the full relevant
changeset (like bugfixes, new features, etc.). Second, because it relies
on every developer making API/ABI changes to remember to store the
change in there during commit break time.
Let's instead always store the entire commit list in changelog, and
let's use TODO-RELEASE only as a list of hints for the maintainer to
help him evaluate how LIBVERSION needs to be bumped for each library.
Other tools such as osmo-abi-check.git can be used to help with the
process of decission too.
Let's take the opportunity too to only commit stuff already added to the
staging area, as it proved easier to manage from my personal experinece
making latest releases.
Change-Id: Ibf662173ce2b4ff3966e9ad5f56c65dfb13607ff
2018-05-03 13:01:47 +00:00
|
|
|
MAKEMOD=`git diff --cached -GLIBVERSION --stat | grep Makefile.am`
|
2017-10-03 08:54:41 +00:00
|
|
|
ISODATE=`date -I`
|
|
|
|
|
|
|
|
if [ "z$BUMPVER" = "z" ]; then
|
|
|
|
echo Unable to find 'bumpversion' command.
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ "z$NEW_VER" = "z" ]; then
|
|
|
|
echo "Please fix versioning to match http://semver.org/ spec (current is $VERSION) before proceeding."
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
echo "Releasing $VERSION -> $NEW_VER..."
|
|
|
|
|
osmo-release.sh: Always generate entire commit changelog
Before this commit, for library projects (containing LIBVERSION in some
Makefile), the entire commit list was not stored into the changelog, but
only a few lines from TODO-RELEASE files.
This is a bad approach for several reasons. First, because that file was
only aimed at containing API/ABI breaks, and not the full relevant
changeset (like bugfixes, new features, etc.). Second, because it relies
on every developer making API/ABI changes to remember to store the
change in there during commit break time.
Let's instead always store the entire commit list in changelog, and
let's use TODO-RELEASE only as a list of hints for the maintainer to
help him evaluate how LIBVERSION needs to be bumped for each library.
Other tools such as osmo-abi-check.git can be used to help with the
process of decission too.
Let's take the opportunity too to only commit stuff already added to the
staging area, as it proved easier to manage from my personal experinece
making latest releases.
Change-Id: Ibf662173ce2b4ff3966e9ad5f56c65dfb13607ff
2018-05-03 13:01:47 +00:00
|
|
|
if [ "z$LIBVERS" != "z" ]; then
|
2017-10-03 08:54:41 +00:00
|
|
|
if [ "z$MAKEMOD" = "z" ]; then
|
2018-05-02 13:58:37 +00:00
|
|
|
echo "Before releasing, please modify some of the libversions: $LIBVERS"
|
osmo-release.sh: Always generate entire commit changelog
Before this commit, for library projects (containing LIBVERSION in some
Makefile), the entire commit list was not stored into the changelog, but
only a few lines from TODO-RELEASE files.
This is a bad approach for several reasons. First, because that file was
only aimed at containing API/ABI breaks, and not the full relevant
changeset (like bugfixes, new features, etc.). Second, because it relies
on every developer making API/ABI changes to remember to store the
change in there during commit break time.
Let's instead always store the entire commit list in changelog, and
let's use TODO-RELEASE only as a list of hints for the maintainer to
help him evaluate how LIBVERSION needs to be bumped for each library.
Other tools such as osmo-abi-check.git can be used to help with the
process of decission too.
Let's take the opportunity too to only commit stuff already added to the
staging area, as it proved easier to manage from my personal experinece
making latest releases.
Change-Id: Ibf662173ce2b4ff3966e9ad5f56c65dfb13607ff
2018-05-03 13:01:47 +00:00
|
|
|
echo "You should NOT be doing this unless you've read and understood following article:"
|
|
|
|
echo "https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info"
|
2018-05-02 13:58:37 +00:00
|
|
|
exit 1
|
2017-10-03 08:54:41 +00:00
|
|
|
fi
|
osmo-release.sh: Always generate entire commit changelog
Before this commit, for library projects (containing LIBVERSION in some
Makefile), the entire commit list was not stored into the changelog, but
only a few lines from TODO-RELEASE files.
This is a bad approach for several reasons. First, because that file was
only aimed at containing API/ABI breaks, and not the full relevant
changeset (like bugfixes, new features, etc.). Second, because it relies
on every developer making API/ABI changes to remember to store the
change in there during commit break time.
Let's instead always store the entire commit list in changelog, and
let's use TODO-RELEASE only as a list of hints for the maintainer to
help him evaluate how LIBVERSION needs to be bumped for each library.
Other tools such as osmo-abi-check.git can be used to help with the
process of decission too.
Let's take the opportunity too to only commit stuff already added to the
staging area, as it proved easier to manage from my personal experinece
making latest releases.
Change-Id: Ibf662173ce2b4ff3966e9ad5f56c65dfb13607ff
2018-05-03 13:01:47 +00:00
|
|
|
if [ -f "TODO-RELEASE" ]; then
|
|
|
|
grep '#' TODO-RELEASE > TODO-RELEASE.clean
|
|
|
|
mv TODO-RELEASE.clean TODO-RELEASE
|
|
|
|
git add TODO-RELEASE
|
|
|
|
fi
|
2017-10-03 08:54:41 +00:00
|
|
|
fi
|
osmo-release.sh: Always generate entire commit changelog
Before this commit, for library projects (containing LIBVERSION in some
Makefile), the entire commit list was not stored into the changelog, but
only a few lines from TODO-RELEASE files.
This is a bad approach for several reasons. First, because that file was
only aimed at containing API/ABI breaks, and not the full relevant
changeset (like bugfixes, new features, etc.). Second, because it relies
on every developer making API/ABI changes to remember to store the
change in there during commit break time.
Let's instead always store the entire commit list in changelog, and
let's use TODO-RELEASE only as a list of hints for the maintainer to
help him evaluate how LIBVERSION needs to be bumped for each library.
Other tools such as osmo-abi-check.git can be used to help with the
process of decission too.
Let's take the opportunity too to only commit stuff already added to the
staging area, as it proved easier to manage from my personal experinece
making latest releases.
Change-Id: Ibf662173ce2b4ff3966e9ad5f56c65dfb13607ff
2018-05-03 13:01:47 +00:00
|
|
|
gbp dch --debian-tag='%(version)s' --auto --meta --git-author --multimaint-merge --ignore-branch --new-version="$NEW_VER"
|
2017-10-03 08:54:41 +00:00
|
|
|
dch -r -m --distribution "unstable" ""
|
osmo-release.sh: Always generate entire commit changelog
Before this commit, for library projects (containing LIBVERSION in some
Makefile), the entire commit list was not stored into the changelog, but
only a few lines from TODO-RELEASE files.
This is a bad approach for several reasons. First, because that file was
only aimed at containing API/ABI breaks, and not the full relevant
changeset (like bugfixes, new features, etc.). Second, because it relies
on every developer making API/ABI changes to remember to store the
change in there during commit break time.
Let's instead always store the entire commit list in changelog, and
let's use TODO-RELEASE only as a list of hints for the maintainer to
help him evaluate how LIBVERSION needs to be bumped for each library.
Other tools such as osmo-abi-check.git can be used to help with the
process of decission too.
Let's take the opportunity too to only commit stuff already added to the
staging area, as it proved easier to manage from my personal experinece
making latest releases.
Change-Id: Ibf662173ce2b4ff3966e9ad5f56c65dfb13607ff
2018-05-03 13:01:47 +00:00
|
|
|
git add debian/changelog
|
2017-10-03 08:54:41 +00:00
|
|
|
bumpversion --current-version $VERSION $REL --tag --commit --tag-name $NEW_VER --allow-dirty
|
2018-05-03 13:25:11 +00:00
|
|
|
git commit --amend # let the user add extra information to the release commit.
|
2017-10-03 08:54:41 +00:00
|
|
|
git tag -s $NEW_VER -f -m "Release v$NEW_VER on $ISODATE."
|
|
|
|
echo "Release $NEW_VER prepared, tagged and signed."
|