Release script #5372
Release script #5372
Conversation
1d47829 to
4f0c789
Compare
|
This looks good to me overall. I wonder if we might want to change the name of the release that we upload, away from "Source code" to disambiguate it from the GitHub-generated ones... Maybe "Release source: libgit2-x.y.z.tar.gz"? Or "Official release source code: ..." or something like that? |
script/release.py
Outdated
| 'VER_MINOR': [ str(version.minor), None ], | ||
| 'VER_REVISION': [ str(version.revision), None ], | ||
| 'VER_PATCH': [ '0', None ], | ||
| 'SOVERSION': [ str(version.minor), None ], |
There was a problem hiding this comment.
What should our strategy for soversion here be in a post-1.0 world? We have a couple of choices - we could just keep it monotonically increasing and it doesn't have to have anything to do with the actual version numbers. But I don't actually love that.
We could track it against the major/minor version numbers, which is consistent with what we've been doing - eg 0.29 -> 29, 1.0 -> 100, 1.1 -> 101. This is the strategy that I'd advocate for.
Everything's better than what I currently have, and I think "Release source: libgit2-x.y.z.tar.gz" is good. Wouldn't it need to be "Release sources", though (plural)?
I see other projects use something like "libgiblib.so.1.0.6", "libgio-2.0.so.0.6000.7", "libgirara-gtk3.so.3.1" etc. So we could change our pattern to "libgit2.so.$MAJOR.$MINOR" with a SOVERSION of "$MAJOR.$MINOR"? |
Or go all the way to "libgit2.so.$MAJOR.$MINOR.$REVISION", where systems provide the typical symlinks from "libgit2.so.$MAJOR" -> "ligit2.so.$MAJOR.$MINOR" -> "libgit2.so.$MAJOR.$MINOR.$REVISION" so applications can choose how specific to be. |
|
Yeah, that's a good idea. I updated the soversion to major.minor in 2827c8a |
03a97d7 to
2ae45bc
Compare
Python's PEP 8 specifies that one shall use spaces instead of tabs as coding style, and we actually honor that currently. Our EditorConfig does not special-case Python scripts, though, which is why we end up with our C coding style and thus with tabs. Special-case "*.py" files to override that default with spaces to fix this.
The current release process is not documented in any way. As a result,
it's not obvious how releases should be done at all, like e.g. which
locations need adjusting.
To fix this, let's introduce a new script that shall from now on be used
to do all releases. As input it gets the tree that shall be released,
the repository in which to do the release, credentials to
authenticate against GitHub and the new version. E.g. executing the
following will create a new release v0.32:
$ ./script/release.py 0.32.0 --user pks-t --password ****
While the password may currently be your usual GitLab password, it's
recommended to use a personal access token intead.
The script will then perform the following steps:
1. Verify that "include/git2/version.h" matches the new version.
2. Verify that "docs/changelog.md" has a section for that new
version.
3. Extract the changelog entries for the current release from
"docs/changelog.md".
4. Generate two archives in "tar.gz" and "zip" format via "git
archive" from the tree passed by the user. If no tree was passed,
we will use "HEAD".
5. Create the GitHub release using the extracted changelog entries
as well as tag and name information derived from the version
passed by the used.
6. Upload both code archives to that release.
This should cover all steps required for a new release and thus ensures
that nothing is missing that shouldn't be.
The current release process is not documented in any way. As a result,
it's not obvious how releases should be done at all, like e.g. which
locations need adjusting.
To fix this, let's introduce a new script that shall from now on be used
to do all releases. As input it gets the tree that shall be released,
the repository in which to do the release, credentials to
authenticate against GitHub and the new version. E.g. executing the
following will create a new release v0.32:
While the password may currently be your usual GitLab password, it's
recommended to use a personal access token intead.
The script will then perform the following steps:
This should cover all steps required for a new release and thus ensures
that nothing is missing that shouldn't be.
Note that it seems to be impossible to turn off GitHub's auto-generated archives, so I find it questionable whether it makes sense to upload our own code archives. We can control them better though, which would allow us to fix e.g. #5343. On the other hand, users might be confused when there's seemingly multiple downloads for the same thing.
We could probably counteract that by giving proper names. Right now they're the same as the default generated ones. See https://github.com/pks-t/test/releases for some examples of releases done via that script.
Anyway, even if we end up not generating our own tarballs I feel like having this script is a good step.