versioned releases?

[bagder]

I think it would be beneficial to start doing wcurl releases using classical semver versions, and then also to mark them as releases here on GitHub so that the release feature works as people might expect.

[samueloph]

Using the GitHub releases functionality was suggested in #21 (comment) and I will do that sometime during the next 7 days.

Regarding the versioning, we are currently using calver, I prefer calver over semver for something like wcurl, at least while wcurl sticks to being a simple wrapper. If it ends up rewritten, with more fancy features, then I would prefer semver.

My expectations for wcurl is that we won't have a lot of releases, the only next changes I'm expecting are the ones being discussed in https://salsa.debian.org/debian/wcurl/-/merge_requests/4. I would like to sort that out before the end of the month, and then I don't expect any new releases to happen.

If/when we decide to switch over to semver, this would require starting with some number that's higher than 2024.

Let me know if you have any specific preferences for semver over calver. I will keep this issue open until we start using the GitHub releases.

[bagder]

I can live with calver, I just personally prefer semver. Especially if a long time might pass between releases as then the date risk start feeling old.

If/when we decide to switch over to semver, this would require starting with some number that's higher than 2024.

IMHO, I think that if you would switch over now or soon, it could be okay to go down to 0.x or 1.x as this is still early days in wcurl time. I think we can accept some leeway and "trying out things" in the tool's childhood.

[samueloph]

IMHO, I think that if you would switch over now or soon, it could be okay to go down to 0.x or 1.x as this is still early days in wcurl time. I think we can accept some leeway and "trying out things" in the tool's childhood.

Unfortunately there's no turning back for any who have shipped wcurl already, if we switch to semver and start with something lower than 2024, those who already ship wcurl will have to implement workarounds such as epochs (e.g.: prepending 1: to the version string).

In hindsight, seems like it's a good idea to always prepend calver with 0. to allow a seamless change to semver, but it's too late now.

I'll discuss this with @sergiodj in our weekly call this Thursday.

[sergiodj]

I don't have a strong preference here, but I tend to like semver better, too. I think calver makes a lot of sense when your software release schedule is calendar-oriented, which is not our case here.

OTOH, as @samueloph said, now that we have already released wcurl using calver and given the fact that we don't really expect to have a lot of releases for the project (for now), maybe it just makes sense to stick with this versioning scheme.

When we rewrite wcurl in C using libcurl, then I believe we should just bite the bullet and switch to semver.

[classabbyamp]

as a downstream distributor (linux distro), switching sooner rather than later will make the transition easier, especially for package manages that don't have the capability to go "backwards" in versions (be that reverts, epoch, or other mechanism)

[samueloph]

We will not change the versioning scheme, we will stick to calver to avoid any issues for those who already ship wcurl as its own package.

I will close this issue once I do start using the "releases" feature of GitHub, which should happen on this weekend.

[samueloph]

We now have a GitHub release at https://github.com/curl/wcurl/releases and we'll keep using that moving forward.