If anyone can figure out all the non-mentioned API changes and write them here it would be useful for people like me to avoid having to reverse engineer things
Lots of things, but mainly that lemmy is pretty stable, and its been a year since the last breaking changes release.
I was also kind of opposed to a v1.0, and wanted lemmy to be considered alpha/beta level software, because I know when we release a v.1.0, people are going to expect the same enterprise-level and bug-free software from a ~4 person dev team as they do from a multi-million dollar company. Also it gives us less freedom to make breaking changes, which can be restrictive for back-end devs.
But now we can just adopt proper semver, and the next breaking changes releases can upgrade the MAJOR version.
On the other hand it gives an indication to client developers that such big breaking changes wont be a regular occurence. So they have a reason to upgrade and then keep using 1.0 long-term. I believe that practically all the needed breaking changes are already implemented, and remaining issues are mostly new feature requests which can be added as new api endpoints or parameters.
Good callout. I'm actually admin on this instance so it wouldn't apply to me by my reading of the code. Lemmy schedule also doesn't currently use the scheduled posts Lemmy feature, it tracks it separately. Still good to know though, thanks.
Ah, good to know before I start developing. Can you let me know when we can start the development as I don't want to use the API and then discover it's missing more PRs?
I can't say yet, as we're still adding things. If you're not using lemmy-js-client, then as long as your types are generated from it's main branch directly, then you should be fine.
I'm not using the js-client. I'm updating pythorhead so I need to make sure the API is at the final version before I can match it. And to match it I need the patches to be in so I can read the doc, and/or import the swagger.
I will do what I can in advance, but to do the pre-development you asked for, we do need the final version up somewhere.
The final api version would probably be in 1.0-beta.0, which will still take a few months. But at this time you can already start to adapt for the major changes like combined endpoints, and give feedback if anything else in the api needs changing.
Visibility to who? Normies? Search engines favoring corpo slop? You could make a readonly mirror if felt it necessary (it isn’t). If you have a modus operandi for you product or service, you would be better off choosing tools that align with those ideals. This instead says collaborator privacy/freedom is not our priority & we don’t actually follow our values.
I ran a large open source project, and when we switched to Gitlab the number of contributors dropped like a rock. Despite linking to our Gitlab repo everywhere, people weren't finding it on Google or GitHub search, and those who did weren't interested in creating a second account.
We went from probably getting a new contributor every month to maybe getting a couple a year. It significantly slowed down progress.
Oof, lots of work to do for everyone.
If anyone can figure out all the non-mentioned API changes and write them here it would be useful for people like me to avoid having to reverse engineer things
I can say I was there when Lemmy 1.0 released!
Does this mean Lemmy 0.20 is now 1.0? What prompted the change?
Lots of things, but mainly that lemmy is pretty stable, and its been a year since the last breaking changes release.
I was also kind of opposed to a
v1.0, and wanted lemmy to be considered alpha/beta level software, because I know when we release av.1.0, people are going to expect the same enterprise-level and bug-free software from a ~4 person dev team as they do from a multi-million dollar company. Also it gives us less freedom to make breaking changes, which can be restrictive for back-end devs.But now we can just adopt proper semver, and the next breaking changes releases can upgrade the MAJOR version.
On the other hand it gives an indication to client developers that such big breaking changes wont be a regular occurence. So they have a reason to upgrade and then keep using 1.0 long-term. I believe that practically all the needed breaking changes are already implemented, and remaining issues are mostly new feature requests which can be added as new api endpoints or parameters.
are you at a liberty to say what the feature requests you're looking at are?
What feature requests? Everything that's open on the issue tracker really.
Maturity I think. New Lemmy is good enough to make the change.
And here I was thinking it would go all the way to 0.99 before getting to 1.0...
Holy shit, it's going gold!
A lot of these should not be called breaking changes. A new API is not a breaking change if the old API remains.
Yeah but those changes break clients as soon as they turn down the old API.
Indeed, dropping the old API would be the breaking change.
Rich Hickey did a fantastic talk on versioning, breaking changes, and dependencies.
Will the new lemmy ui be ready for 1.0?
Can't give an ETA yet. I've got a few more back-end things to finish up, then @sleeplessone1917 and I will work on lemmy-ui.
Then I also gotta work on getting jerboa updated also. So much work and so few developers.
Yes we always release backend and frontend versions together.
This is epic. I really hope Laurence can find some time to make Sync for Lemmy support it.
Excited to see the idempotency feature. That will help a lot with double posts from using https://github.com/RikudouSage/LemmySchedule
Idk if it will be useful to more active people like you because you will be able to schedule only up to 10 posts at once: https://github.com/N4Y-docker/lemmy-nightly/commit/9eee61dd06220176fbb97ccbba4a594ea21bb5c6
Good callout. I'm actually admin on this instance so it wouldn't apply to me by my reading of the code. Lemmy schedule also doesn't currently use the scheduled posts Lemmy feature, it tracks it separately. Still good to know though, thanks.
Oh, didn't realise that you were an admin there. haha
Oh yes!
Really looking forward to SSO support!
Nice
Does this mean you renamed just the DB columns, but not the API keys?
They're all renamed, that PR just hasn't been deployed to voyager.lemmy.ml yet.
Ah, good to know before I start developing. Can you let me know when we can start the development as I don't want to use the API and then discover it's missing more PRs?
I can't say yet, as we're still adding things. If you're not using lemmy-js-client, then as long as your types are generated from it's main branch directly, then you should be fine.
I'm not using the js-client. I'm updating pythorhead so I need to make sure the API is at the final version before I can match it. And to match it I need the patches to be in so I can read the doc, and/or import the swagger.
I will do what I can in advance, but to do the pre-development you asked for, we do need the final version up somewhere.
The final api version would probably be in 1.0-beta.0, which will still take a few months. But at this time you can already start to adapt for the major changes like combined endpoints, and give feedback if anything else in the api needs changing.
The updated spec should be at https://join-lemmy.org/api/main , and it gives you an option to download the
.jsonfileOr you can use the lemmy-js-client main branch, and run
pnpm tsoato generate aswagger.jsonfile.Quick question mostly for @phiresky:
Are you targeting post tags for 1.0 or for later?
Thx for the work.
wow! Huge, just when I am back to the saddle
CORS is broken on voyager.lemmy.ml. Can you please fix it?
K I think it should be fixed now.
Awesome works!
Only thing I’ve noticed so far is the old v3 profile API response doesn’t have posts/comments attached
Yep I think we note that in the breaking changes post. We only serve the combined responses now.
Congratulations. By the way, was this version 0.20.0 previously?
Yes we renamed it.
💪
1.0 would be the perfect time to have the code, bug tracker, etc. migrated off of Microsoft GitHub
Would lose a lot of visibility. Gotta pick your battles
Visibility to who? Normies? Search engines favoring corpo slop? You could make a readonly mirror if felt it necessary (it isn’t). If you have a modus operandi for you product or service, you would be better off choosing tools that align with those ideals. This instead says collaborator privacy/freedom is not our priority & we don’t actually follow our values.
I ran a large open source project, and when we switched to Gitlab the number of contributors dropped like a rock. Despite linking to our Gitlab repo everywhere, people weren't finding it on Google or GitHub search, and those who did weren't interested in creating a second account.
We went from probably getting a new contributor every month to maybe getting a couple a year. It significantly slowed down progress.
Really excited for these changes; scheduled posts, donations, SSO, let's goo
Will there be an overlap period where both APIs function?
Yes the current api v3 is also available in 1.0 alpha
Perfect, thank you.