Release 0.99 #5291
Release 0.99 #5291
Conversation
|
@ethomson
Could you also include this PR in this release? |
|
@lolgear Done. Thanks! |
|
Sounds good to me. We're long overdue for a new release anyway, and there has been quite a lot of work since the last one. I'll make sure to have another go at #5123 this week to get it merged. Not sure whether I can provide valuable input for #5285 or 5286, but I'll see. I think we should aim to get #5282 merged, too, and maybe even #5243. Otherwise I'm fine. |
|
Here's my "nomination" list I would have personally liked:
|
|
@ethomson |
fc8f3fe to
2948c32
Compare
|
I've updated this with more recent changes and authors (as of |
6abffe6 to
f20c0cf
Compare
The final piece we're waiting on is #5286. It's probably going to get merged soonish, after which we'll wait one or two weeks to let it settle before we release v0.99. |
f20c0cf to
11de7f6
Compare
|
@pks-t am i okay to merge this or would it break your release script with the version updates? |
You mean with the autors amended? That's fine, the script currently only searches until the next version section and includes everything between current and previous header. Would mean that these authors are part of the release notes, but I consider it a good thing to give credit where credit is due. Anyway, one thing I notice is that my scripting is currently too strict. It verifies that for a version X, that the release section's previous release is X-1. So e.g. for v0.27.1 it would be v0.27.0 or v0.27, for v0.28 it would be v0.27.x. With the jump to v0.99 we're breaking this assumption. Furthermore, the current assumption is that the soversion matches our minor version, which obviously also breaks with v0.99. Guess I should just remove that check altogether and only verify MAJOR/MINOR/REVISION. Anyway, I guess I'll fine tune the release script anyway as soon as we're ready to go, and a second pair of eyes would be a good thing, too. |
Ah, didn't see you've done a review already. |
I was worried about the version updates that I'd done in |
|
On Sun, Feb 02, 2020 at 04:43:20AM -0800, Edward Thomson wrote:
> You mean with the autors amended?
I was worried about the version updates that I'd done in `include/git2/version.h`.
You can always run the script with "--dryrun". It will tell if
there's anything it doesn't like, but won't do any uploading
stuff. Anyway, I'll update the script to loosen the version check
for our changelog and use the MAJOR.MINOR soversion.
|
| #define LIBGIT2_VER_REVISION 0 | ||
| #define LIBGIT2_VER_PATCH 0 | ||
|
|
||
| #define LIBGIT2_SOVERSION 28 | ||
| #define LIBGIT2_SOVERSION "0.99" |
There was a problem hiding this comment.
Hum. Any reason why we don't go all the way and say "0.99.0", matching LIBGIT2_VERSION?
There was a problem hiding this comment.
I don't think that we want our soversion to include teeny version numbers - IMO, we shouldn't be making ABI incompatible changes in teeny releases. Are there other considerations that we should be thinking about?
With this change, we also get a nice set up of our library links on the filesystem:
1852 -rwxr-xr-x 1 ethomson staff 1895388 Feb 3 10:51 libgit2.0.99.0.dylib*
0 lrwxr-xr-x 1 ethomson staff 20 Feb 3 10:51 libgit2.0.99.dylib@ -> libgit2.0.99.0.dylib
0 lrwxr-xr-x 1 ethomson staff 18 Feb 3 10:51 libgit2.dylib@ -> libgit2.0.99.dylib
|
On Mon, Feb 03, 2020 at 02:53:02AM -0800, Edward Thomson wrote:
ethomson commented on this pull request.
> #define LIBGIT2_VER_REVISION 0
#define LIBGIT2_VER_PATCH 0
-#define LIBGIT2_SOVERSION 28
+#define LIBGIT2_SOVERSION "0.99"
I don't think that we want our soversion to include teeny version numbers - IMO, we shouldn't be making ABI incompatible changes in teeny releases. Are there other considerations that we should be thinking about?
With this change, we also get a nice set up of our library links on the filesystem:
```
1852 -rwxr-xr-x 1 ethomson staff 1895388 Feb 3 10:51 libgit2.0.99.0.dylib*
0 lrwxr-xr-x 1 ethomson staff 20 Feb 3 10:51 libgit2.0.99.dylib@ -> libgit2.0.99.0.dylib
0 lrwxr-xr-x 1 ethomson staff 18 Feb 3 10:51 libgit2.dylib@ -> libgit2.0.99.dylib
Fair enough. Quoting CMake's documentation [1]:
For shared libraries and executables on Windows the VERSION
attribute is parsed to extract a <major>.<minor> version
number. These numbers are used as the image version of the
binary.
So CMake already expects "major.minor", which is another argument
in favor of leaving out "revision". I've updated the release
script to reflect that.
[1]: https://cmake.org/cmake/help/v3.15/prop_tgt/SOVERSION.html
|
docs/changelog.md
Outdated
| @@ -1,5 +1,283 @@ | |||
| v0.28 + 1 | |||
| v0.99 | |||
| --------- | |||
There was a problem hiding this comment.
The script expects a newline between "----" and the body and complains if it doesn't find it. Initially, I've also had a check that verifies that section header and version are of equal lengths, but I've dropped that
Give the release a name, "Torschlusspanik" (the fear that time is running out to act). Indeed, the time is running out for changes to be included in v1.0.
This commit also switches our SOVERSION to be "$MAJOR.$MINOR" instead of "$MINOR", only. This is in preparation of v1.0, where the previous scheme would've stopped working in an obvious way.
|
I've made one amendment to fix up the missing newline after the version header in our changelog. While at it, I've squashed commits so that we only have one for our changelog and one for bumping the version. |
I want to release an 0.99 in advance of a 1.0.
This is basically a 1.0 release candidate but we have historically not seen a lot of people installing "release candidates" in production and using them seriously. We want Serious Work on this release candidate, so let's call it an 0.99, and a real release.
After that, I propose that we take a branch for 1.0 and keep working in master on post-1.0 work.
What else are we waiting on for 0.99:
git_off_ttogit_object_size_t#5123Cut:
#5286 - this is an annoying bug if you hit it but it's very rare, so I'm tempted to just kick it out to post-1.0