search

TopoToolbox / libtopotoolbox

A C library for the analysis of digital elevation models.
https://topotoolbox.github.io/libtopotoolbox/
GNU General Public License v3.0
0 stars 3 forks source link

Implement automatic weekly releases #51

Closed wkearn closed 1 week ago

wkearn commented 2 weeks ago

This PR implements a GitHub Actions workflow that automatically tags and releases a source code archive every Monday.

We are starting to get to the point where we need better control over which version of libtopotoolbox we are using in downstream projects. There are some outstanding issues (namely #23) that I have held off on because they will break pytopotoolbox, and we don't have a good way of cleanly managing that transition.

These releases are not meant to be "official" libtopotoolbox releases. They exist only to allow downstream projects to pin the version of libtopotoolbox they are currently using. The version numbering explicitly does not follow semantic versioning, and each weekly release should be considered potentially breaking. A disclaimer to that effect is included in the release notes.

The tags have the format 2024-W26 using the year and the ISO week number. Thus pytopotoolbox can say, in its CMakeLists.txt file:

FetchContent_Declare(
  topotoolbox
  GIT_REPOSITORY https://github.com/TopoToolbox/libtopotoolbox.git
  GIT_TAG 2024-W26
)

to ensure that it always grabs the week 26 version of libtopotoolbox once that version has been released.

Once things stabilize a bit more across the TopoToolbox ecosystem, we might consider changing the release cycle and version numbering scheme.

@Teschl: does this make sense? Once we make the first release for libtopotoolbox, we should pin the version number in pytopotoolbox's CMakeLists.txt. A release won't be automatically created until next Monday, but I will manually create one once I merge this PR.

Teschl commented 1 week ago

I think this should work well :+1:. But it will create a lot of (potentially unused) releases, right? How do we handle that? When we create releases for the pytopotoolbox this will be very useful to not break old versions.

We could also create a new branch for each release. Then we would have main, v3.1, v3.2, [...]. I have no experience with this, but this is how seaborn does it.

wkearn commented 1 week ago

It will create a lot of releases, but I don't think GitHub imposes limitations on the number of releases. I should note that we would get the same benefit by fixing the commit hash that pytopotoolbox downloads and builds with -- the weekly release just labels things a bit more nicely and gives us a handy link to download stuff from. The weekly release tags also don't make the promises of semantic versioning. While we're still developing things quickly on our own and working out what the interface between libtopotoolbox and the packages looks like, I think it makes sense not to worry too much about what constitutes a breaking change. At some point, it might make sense to reevaluate the system, especially if people start using libtopotoolbox outside of our officially supported packages.

I think the branching workflow is most useful when you need to support multiple versions "in the wild," where some users are using v1.0 and some are using v2.0 and for whatever reason the v1.0 users don't want to upgrade to v2.0, but they still need bugfixes and security patches even if they don't use the new features. Then you can cherry-pick the bugfixes into the v1.0 branch and release v1.1. This strategy makes more sense for user-facing packages like pytopotoolbox, and we should probably not use the same versioning and release strategy there as I am proposing here. The package registries and users of packages probably also expect something more like semantic versioning.

wkearn commented 1 week ago

Ignore this excesstopography commit. That's a fix for #53. I pushed to the wrong branch.