hometown-fork / hometown

A supported fork of Mastodon that provides local posting and a wider range of content types.
GNU Affero General Public License v3.0
743 stars 55 forks source link

Swap the version numbers or add identifier (ideally, both) #1213

Closed halcy closed 1 year ago

halcy commented 1 year ago

Pitch

If it's not too much of a problem, it'd help me a lot if you either:

a) swapped the version numbers, so that the base Mastodon version comes first b) added an identifier string, e.g. make the version something like "hometown-(hometown version)+(mastodon version)" so I can easily check for that c) both: "(mastodon version)+hometown-(hometown version)"

Motivation

I'm the maintainer of Mastodon.py. Mastodon.py uses the version number that Mastodon reports in /api/v1/instance to disambiguate various api calls and check if features are supported. This is currently a problem with hometown instances, since they reprot the version as (hometown version)+(mastodon version). I can't simply parse the version after the + if a + is present, because a lot of instances actually use something like (mastodon version)+(instance name) for their local fork. In the current version, I'm trying to support working on hometown properly by default, and I have to do a wacky workaround where I try to parse the part after the + as a version and if that succeeds I assume it's hometown (while accounting for Pleroma, which also has an extended version string, but they put an identifier there, so that is at least easier. It is still a bit of a mess).

dariusk commented 1 year ago

Hi @halcy, thanks for all your work on third party libraries. I was actually working on a PR to your library for this but other things came up -- anyway, excited to hear you are looking to support Hometown.

Changing how we do semver is probably ultimately the right call. Even though the semver nerds told me to do this way, I see no reason to not keep the actual version synced with Mastodon and to make the "build metadata" after the plus into the hometown version.

As much as it pains me to look at it, I think I will go with your "both" option. So the current release would look something like

3.5.5+hometown-1.0.7

I might just do a minor hometown release (before the big v4 merge) in part to get used to the new versioning and update all the documentation, let my users know, etc. So maybe I'll merge in some patches that don't have to do with v4 and make a 3.5.5+hometown-1.0.8 release.

halcy commented 1 year ago

Hey,

yeah, this is definitely a “correct” vs “unfortunately, in reality” type situation. I do have a workaround in the current version of Mastodon.py which should be able to deal with almost any variant anyone uses, so now for me it’s more trying to get everyone to do the most common thing, so that it’s so common that no one gets the idea to do something new that’ll just make it completely ambiguous. Thanks for considering it!

dariusk commented 1 year ago

This is fixed in the upcoming v1.0.8 release.