Unverified Commit 809b0ca6 by Edward Thomson Committed by GitHub

Merge pull request #4533 from pks-t/pks/v0.27.0-rc1

v0.27.0-rc1: version bump
parents 894ccf4b 23d4a91b
v0.26 + 1 v0.27 + 1
---------
### Changes or improvements
### API additions
### API removals
### Breaking API changes
v0.27
--------- ---------
### Changes or improvements ### Changes or improvements
...@@ -54,6 +65,12 @@ v0.26 + 1 ...@@ -54,6 +65,12 @@ v0.26 + 1
* Fix files not being treated as modified when only the file mode has changed. * 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. * Fix for WinHTTP not properly handling NTLM and Negotiate challenges.
* When using SSH-based transports, we now repeatedly ask for the passphrase to * When using SSH-based transports, we now repeatedly ask for the passphrase to
......
...@@ -23,6 +23,13 @@ We aim to release once every six months. We start the process by opening an issu ...@@ -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. 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 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. This is the first release of the v0.X series, <codename>. The changelog follows.
......
...@@ -7,12 +7,12 @@ ...@@ -7,12 +7,12 @@
#ifndef INCLUDE_git_version_h__ #ifndef INCLUDE_git_version_h__
#define 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_MAJOR 0
#define LIBGIT2_VER_MINOR 26 #define LIBGIT2_VER_MINOR 27
#define LIBGIT2_VER_REVISION 0 #define LIBGIT2_VER_REVISION 0
#define LIBGIT2_VER_PATCH 0 #define LIBGIT2_VER_PATCH 0
#define LIBGIT2_SOVERSION 26 #define LIBGIT2_SOVERSION 27
#endif #endif
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment