Closed ahmedHusseinF closed 1 year ago
@jmikrut
Thanks @ahmedHusseinF, I agree with your sentiments.
Unfortunately though your suggestion falls under the old saying of closing the barn door after the horse is gone.
Even if we move to ~
in front of the version now, the previous projects won't get it and these breaking change minors are already released. Going forward we are committed to following semver guidelines and only having breaking changes released on major point releases, so changing to ~
won't matter for new projects.
We just have to do the best we can going forward. What do you think?
Hello @DanRibbens ,
Actually I agree with you more on this one.
My solution was on the assumption that you had a high level goal of not incrementing the major version since payload moves fast and has breaking changes often and that would lead to something like react, having version 20 or something very soon.
Also I think all of this should be mentioned in a FAQ somewhere to let people quickly find the solution if they had the same experience as mine.
Thank you anyway for the fast response.
We do like to go fast, but that doesn't mean we have to break existing projects. The only place I can think where people would see it is in the main repo readme, perhaps some messaging there could work.
Cheers!
Closing as we plan on following semver v2 and beyond.
I think this issue should be opened here so here we go.
When creating a new payload app, the package.json version defaults to
^latest version whatever
.The issue happened when i had a 1.4.1 payload app that somehow i deleted the yarn.lock/node_modules and needed a fresh
yarn install
.This allowed yarn to match payload version to the latest 1.7.2 which has many breaking changes and failed to build the app.
I think each project should be generated with semver syntax like this
~payload version
to update to the latest patch version only since there is breaking changes with each minor version.