Bookmarks / Favourites breaking change 1.2

boomzilla

Recently, a breaking change (1.2 -> 1.3) was introduced:

refactor src/favourites.js · Issue #5096 · NodeBB/NodeBB

rename uid::favourites to uid::bookmarks rename pid::users_favourited to pid::users_bookmarked rename /favourites route to /bookmarks rename post field reputation to bookmarks separate vote and bookmark code fix langu...

GitHub (github.com)

I didn't see any sort of announcement or warning about this (though admittedly I wasn't watching terribly closely). Was there a public discussion about this? I'm curious as to why you guys introduced this breaking change in a minor release.

Thanks.

PitaJ

@boomzilla NodeBB doesn't follow semver, so what is normally seen as a "minor" release is actually a "major" release for NodeBB.

Tl;dr treat X.Y.Z changes to Y version as major releases for now.

<baris>

Actually we do breaking changes in minor releases and not patch releases, so we don't really follow semver in that regard. If we did that we would be at nodebb 32 now.

I think since 1.x.x we started tagging all breaking changes with the breaking change(plugins) and/or breaking change(themes) so people can adjust their themes and custom code before upgrading.

pichalite

Also 1.3 is not released yet. The only place NodeBB mentions these are in the milestones on github issue tracker. They clearly marked it as breaking change there.

1.3.0 Milestone · NodeBB/NodeBB

Node.js based forum software built for the modern web - 1.3.0 Milestone · NodeBB/NodeBB

GitHub (github.com)

boomzilla

@baris said in Bookmarks / Favourites breaking change 1.2:

Actually we do breaking changes in minor releases and not patch releases, so we don't really follow semver in that regard.

Ah, fair enough.

@pichalite said in Bookmarks / Favourites breaking change 1.2:

Also 1.3 is not released yet.

I know. But it seems like an awful way to run a railroad if you break people's plugins without advance notice, which I don't think is covered by a tag on a github issue.

exodo

I agree with you @boomzilla The lack of information about updates, breaking changes, documentation, etc makes so hard to change between versions cause any plugin may break and that limits the fast adoption of newer releases on the nodebb comunities.
Not every people are programmers to dig between commits and changes on github.
Sadly this situation been long time ago and its not easy to solve because of the modular plugin system.

In my opinion there are a bunch of important plugins that should be mantained by all the community and staff like a core features ( there are some already included ) in order to be sure all works on each release and also thread or blog entry with important changes woudnt hurt.

PitaJ

How do you recommend this be done? If you want a changelog, you can look at the milestone on GitHub.

julian

We do have the NodeBB-Community org, although this is not an official effort and thus there are no guarantees that the listed plugins are compatible

We try to do our best with nbbpm compatibility checks...

exodo

@PitaJ said in Bookmarks / Favourites breaking change 1.2:

How do you recommend this be done? If you want a changelog, you can look at the milestone on GitHub.

But milestones only cover issues. There iare of course lot of changes and addition that arent referenced on issues.
There were some helpful topics of breaking changes on the past with a little explanation.
I guess a topic with centralized information would be nice for 1.2 1.3 1.4 at least updates ( including new or uptades hooks explained + breaking changes on plugins explained + breaking changes on themes explained + a simple explanation of new features)
It doesnt need to be all changes just important things
Please remember that not every body know to code but with some little explanations and documentation some of us can keep runnin and doing small fixes and learning and improving nodebb