Skip to content
This repository has been archived by the owner on Oct 13, 2023. It is now read-only.

Payload self-updates to latest minor version but that breaks compatibility #16

Closed
ahmedHusseinF opened this issue Apr 29, 2023 · 5 comments

Comments

@ahmedHusseinF
Copy link

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.

@ahmedHusseinF
Copy link
Author

@jmikrut

@DanRibbens
Copy link
Contributor

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?

@ahmedHusseinF
Copy link
Author

ahmedHusseinF commented Apr 29, 2023

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.

@DanRibbens
Copy link
Contributor

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!

@denolfe
Copy link
Member

denolfe commented Jul 5, 2023

Closing as we plan on following semver v2 and beyond.

@denolfe denolfe closed this as completed Jul 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants