Commit 809b0ca6b9b6a5648b8e802a9f0c6a0821257595
2018-02-20T22:06:53
Merge pull request #4533 from pks-t/pks/v0.27.0-rc1 v0.27.0-rc1: version bump
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 94b28b1..73d19de 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,4 +1,15 @@
-v0.26 + 1
+v0.27 + 1
+---------
+
+### Changes or improvements
+
+### API additions
+
+### API removals
+
+### Breaking API changes
+
+v0.27
---------
### Changes or improvements
@@ -54,6 +65,12 @@ v0.26 + 1
* Fix files not being treated as modified when only the file mode has changed.
+* We now explicitly reject adding submodules to the index via
+ `git_index_add_frombuffer`.
+
+* Fix handling of `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` raising `SIGABRT` when
+ one file has been deleted and another file has been rewritten.
+
* Fix for WinHTTP not properly handling NTLM and Negotiate challenges.
* When using SSH-based transports, we now repeatedly ask for the passphrase to
diff --git a/docs/release.md b/docs/release.md
index f9bbd65..42f032b 100644
--- a/docs/release.md
+++ b/docs/release.md
@@ -23,6 +23,13 @@ We aim to release once every six months. We start the process by opening an issu
We tag at least one release candidate. This RC must carry the new version in the headers, including the SOVERSION. If there are no significant issues found, we can go straight to the release after a single RC. This is up to the discretion of the release manager. There is no set time to have the candidate out, but we should we should give downstream projects at least a week to give feedback.
+Preparing the first release candidate includes updating the version number of libgit2 to the new version number. To do so, a pull request shall be submitted that adjusts the version number in the following places:
+
+- CHANGELOG.md
+- include/git2/version.h
+
+As soon as the pull request is merged, the merge commit shall be tagged with a lightweight tag.
+
The tagging happens via GitHub's "releases" tab which lets us attach release notes to a particular tag. In the description we include the changes in `CHANGELOG.md` between the last full release. Use the following as a base for the release notes
This is the first release of the v0.X series, <codename>. The changelog follows.
diff --git a/include/git2/version.h b/include/git2/version.h
index becf97b..746bf42 100644
--- a/include/git2/version.h
+++ b/include/git2/version.h
@@ -7,12 +7,12 @@
#ifndef INCLUDE_git_version_h__
#define INCLUDE_git_version_h__
-#define LIBGIT2_VERSION "0.26.0"
+#define LIBGIT2_VERSION "0.27.0"
#define LIBGIT2_VER_MAJOR 0
-#define LIBGIT2_VER_MINOR 26
+#define LIBGIT2_VER_MINOR 27
#define LIBGIT2_VER_REVISION 0
#define LIBGIT2_VER_PATCH 0
-#define LIBGIT2_SOVERSION 26
+#define LIBGIT2_SOVERSION 27
#endif