`pre mode` will cause conflict and blocking our collaborate on git flow (merge / rebase / cherry-pick)

Problem

One of the greatest strengths of the changesets is that all the xxx-changeset.md files are distributed, so we can easily collaborate on merge / rebase / cherry-pick without any worry about conflict in changesets.

But in our git flow ([trunk-based development])(https://trunkbaseddevelopment.com/), we will continue to create some pre-release version (with different “tag”) in different release-branches and publish for testing.

Due to the pre mode will always create pre.json file, and it’s a “single point”, not like distributed changeset files, so when we try to merge our branches, pre.json will always cause conflict ☹️.

Proposed solution

Maybe deprecate the design of pre.json in changesets v3?

IMHO the pre.json only record two things, which changeset files consumed (as changelog) by bump pre version with which pre-release id (“pre-id” same as “tag” in changesets).

I think both of two can record in changeset files themselves, in yaml front-matter, like

---
"@changesets/cli": patch
pre-release-tag: alpha
pre-consumed: true
---

...

In that design, pre-release-tag(or any other key word) is created in changeset add, pre-consumed is marked in like changeset version --pre-release if it has pre-release-tag, otherwise bump to prod version and delete changeset file as current behavior.

And the changeset publish design to always respect current “version” in package.json, the default “publish tag” need parsed from current version, so that the publish is nothing about pre mode at all.

---

propose links to #665 [[Umbrella] Changesets v3]

[Andarist]

The conflict is most likely to happen within a list of changeset IDs - where each new line contains a new changeset ID. So yeah, the situation related to conflicts potentially could be improved with yaml there but I would consider this to not be that big of a problem and something that shouldn’t happen too often. So I’m not really sure if it’s worth it to support a different file format there. Especially that different solutions could be chosen here - like for instance, those changesets could just be moved to a different directory and the list of “committed” changesets wouldn’t have to live the pre.json at all.

[zthxxx]

UPDATE after use rushjs in 6 months: rushjs works well without pre mode or pre.json.