Branches for stable Lemmy releases.

[airblast-dev]

Currently stable releases are made with tags such as 0.19.3. However this makes backporting a fix somewhat difficult as it would in a sense be changing the past.

Lemmy's 0.19.4 is released yet many websites are still using 0.19.3. In case there is a bug that is found across multiple versions of the library (0.19.3, 0.19.4, ...) there is no proper way to handle it. One example would be:

lemmy-client-rs/src/lemmy_client_internal.rs

Line 156 in ce789ee

println!("Response is {hue:?}");

This makes any application that uses the terminal quite difficult to work with. Same applies to the TLS situation as well. My intention is to not point any fingers, but developers including myself will make mistakes but we should be able to correct them. Testing should be written to avoid some of these issues, but that is a different topic.

A solution would be to have a branch for each versions stable release solely for bug fixes, and dependency updates. Of course it would be pretty annoying to deal with 20 different branches, so perhaps the last N (I was thinking 2) stable releases could be supported instead.

Overall I think tying lemmy-client-rs' version strictly to the lemmy's version is a bit problematic when we have to make a fix.

To be able to use the library for version 0.19.3 at all in my terminal application I had to make a fork and change a few parts starting from the 0.19.3 tag. With majority of the changes being backports of this libraries commits with dependency updates (with a few breaking changes as well but those are irrelevant for this issue).

I am open to hear what you think, and I apologize if I came off as aggressive at any point.

Edit: I also looked into how the lemmy repository deals with this issue, however since the intention is that new instances to be the latest stable, such solutions aren't really needed and the solution generally is to just upgrade to the latest stable. The difference for someone using this library is that they will likely not have any saying in which version the lemmy instance will use. Such cases would apply for someone developing a desktop GUI client, that wants to connect to an older lemmy instance.

Edit 2: While a new version is published with a fix (currently 0.19.5-alpha.1) it would mean the user would have to assume 0.19.4 is compatible with with it, and we would have to make sure that 0.19.4 is fully compatible with 0.19.5... . This adds quite a bit of work and, a chance to overlook something that could be avoided by simply sticking to last N stable releases and dealing with those instead.

Note

Also I am aware that this isn't an issue and is more of a discussion but discussions are not enabled so this was the closest thing.

[SleeplessOne1917]

A solution would be to have a branch for each versions stable release solely for bug fixes, and dependency updates. Of course it would be pretty annoying to deal with 20 different branches, so perhaps the last N (I was thinking 2) stable releases could be supported instead.

Overall I think tying lemmy-client-rs' version strictly to the lemmy's version is a bit problematic when we have to make a fix.

The issue you fixed yesterday proved this to be the case. I admittedly thoughtlesly aped how the lemmy-js-client handled versioning, and that has come back to bite me.

I am open to hear what you think, and I apologize if I came off as aggressive at any point.

You didn't come off as aggressive. You pointed out a real problem. My main concern at this point is how to switch to a sane versioning scheme that doesn't cause issues with the old releases, e.g. someone wants to update the version of this library they use as a dependency and crates.io doesn't give them the latest.

[airblast-dev]

My main concern at this point is how to switch to a sane versioning scheme that doesn't cause issues with the old releases, e.g. someone wants to update the version of this library they use as a dependency and crates.io doesn't give them the latest.

I agree its a bit hard to find a good way to provide the latest versions. I can think of two options, but I am sure there are other solutions as well.

Making a completely seperate versioning and using Git

By having a completely seperate version scheme we can simply push the latest and tell users to use the its respective git branch for older lemmy versions. This has the upside of allowing users to safely use older versions without causing confusion. We can tell the users this via the Doc page. The doc page should also mention the lemmy version it currently supports.

The downside is that the user has to manually add the dependency using a git link.

Feature gating older versions

Again with a seperate versioning we push the latest, and provide features that change the exported version. This could internally be done by a branch or tag such as 0.19.3-23. From the users end they are just using the latest supported version, and if they want a version with lemmy's previous stable release its just a feature away.

This would mean versioning would be relatively simple, and from the outside its just a dependency with features.

It also means we would have to track and update the feature for supported versions. For example 0.11.2 is a version we don't support anymore. We remove the feature after N stable releases. To avoid the duplicate dependency (0.19.3 and 0.19.4 being both downloaded when only of them is used) we could also just ship a re-export package with a default feature that pulls in the latest. This is could get complicated and it is a bit unusual as far as I know.

The last one will require a bit of playing around to see if it is viable, and how it would be executed. Though I think it is the most simple solution from the users end.

As for updating with either method should be as simple as a cargo update.

[SleeplessOne1917]

By having a completely seperate version scheme we can simply push the latest and tell users to use the its respective git branch for older lemmy versions. This has the upside of allowing users to safely use older versions without causing confusion. We can tell the users this via the Doc page. The doc page should also mention the lemmy version it currently supports.

The downside is that the user has to manually add the dependency using a git link.

Would a different version scheme require users to specify a branch? I figure I'd still have to put things on different branches, but I don't see why I couldn't still make published releases for older versions.

For instance, I could make a release with the working 0.19.4 changes called version 1.0.0. v0.19.3 and earlier could still stay on v0.19.x. Fixes to things compatible with v0.19.4 and up can be bumped 1.0.x, while things compatible with v0.19.4 and below will have patches bumped on the v0.19.x branch. This might be confusing at first, but as Lemmy's development goes on and more major and minor versions are released, the poorly named version in this repo will be outdated enough that virtually no one would want to use them. Eventually, the versioning starting at 1.x.x will have gone on enough that there isn't a conflict any longer.

Thoughts? I'm not sure I communicated my thoughts as well as I wanted to.

[airblast-dev]

I figure I'd still have to put things on different branches, but I don't see why I couldn't still make published releases for older versions.

I looked into how versioning works with crates.io and you are correct there is no reason we can't do that. Sorry for the confusion.

The solution you mentioned sounds good. If I am understanding correctly Lemmy 0.19.4 would start at 1.0.0 and when Lemmy 0.19.5 releases we would be at 2.0.0? Since their versioning is 0.y.z any version change can be a breaking change which means 1.0.0 -> 2.0.0 for us (of course this includes any breaking changes from us as well). And a bug fix for Lemmy 0.19.4 (1.0.0 for us) would mean we bump to 1.0.1.

Please correct me if I am wrong but wouldn't this limit us to non-breaking changes for older Lemmy versions as we would have to do major version bump? If we do a major version bump it would appear as a newer version on crates.io. Such a case is unlikely to come up but could be required as part of a bug fix. This could be needed in a case where a wrong argument is provided to clientfn! that could technically succeed if it only has missing fields and not extra. This is definitely a rare case but I think it is worth mentioning.

[SleeplessOne1917]

If I am understanding correctly Lemmy 0.19.4 would start at 1.0.0 and when Lemmy 0.19.5 releases we would be at 2.0.0?

No. Patch version upgrades for Lemmy will be minor version upgrades for this library, and minor version upgrades for Lemmy will be major version increases for this library. So when Lemmy 0.19.5 releases, this library will be bumped to version 1.1.0. Pre-0.19.4 will be bumped to 0.20.0 (and probably not receive any updates after that since most of the changes this library will accrue over time will just be adding/changing methods for endpoints).

[SleeplessOne1917]

Closing this as I have released the new versions.