search

payloadcms / create-payload-app

CLI for creating a new Payload project
12 stars 8 forks source link

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

Closed ahmedHusseinF closed 1 year ago

ahmedHusseinF commented 1 year ago

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 commented 1 year ago

@jmikrut

DanRibbens commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Closing as we plan on following semver v2 and beyond.