Releasing prerelease versions without modifying package.json files

Affected Packages

Problem

Let's say we have a UI library that is actively developed and releases are happening multiple times from different branches. The releases from branches are happening for testing or experimentation. These releases should happen with prerelease version numbers.

There's active development on master and on the different branches, so the versions are being modified all the time. As a result, merges and/or rebases are extremely hard due to the conflicts in the version numbers.

Proposed solution

There should be a way to publish prerelease versions without modifications to package.json files. This way, only the regular publishes on master will modify the versions in manifests and conflicts will never happen.

Wouldnt it be somewhat equivalent to this:

version
publish
git reset --hard HEAD~1

Maybe, but changeset should keep track of the prerelease version numbers. Or use some random prerelease versions. Because I might want to do several prerelease publishes from a branch.

Right - I’ve assumed that you would only reuse the versioning part and handle publish on your own and that those prereleases are intended as random or based on commit/date (so actually changesets would need to accept “prerelease-tag” for versioning command). When you have such setup with concurrent branches releasing prereleases at the same time then you dont want to share incremental versioning between them, right? They would just be created out of order at many occasions and would create a kinda weird mess

The branch name could be used as part of the prerelease tag + a counter. But I am fine with a "random" tag as well. Or a custom tag provided to changesets.

So I think your suggestion with a prerelease-tag for the version command would work. I'd do something like

changeset version --prerelease <some hash>
pnpm publish -r
git reset --hard HEAD~1

Maybe even better, if version could accept a --no-commit flag. Then instead of HEAD~1, we could do HEAD.

I personally like the idea 👍

The only downside that I see is that changeset version --prerelease <some hash> will always republish all the packages that have changesets. So even if you make a second prerelease publish, the versions from the previous publish will not be reused. Everything will be published again. Even if some packages were not changed since last publish.

but that is probably fine. Developers should be motivated to merge to master frequently

Republishing might actually make it easier to use those prereleases because without that it could be quite hard to know what versions of different packages you are actually supposed to install - which is somewhat a problem even with stable releases, see #249 .

We definitely want to do something like this. We documented what we wanted this to look like when we first implemented prereleases in our dictionary but we haven't got around to actually implementing it.

snapshot prerelease - A snapshot prerelease is intended to make it easy to test all changes at a particular git commit. It is published at 0.0.0 and uses the git hash as the tag. This should be used as a less formal method than a release candidate to make it easy to install and test changes. An example, if we have a package at 1.0.0, and have a changeset for it to be major bumpred, a snapshot release will be at 0.0.0-ABCDEFGH (the last github hash). If we add more commits, the next snapshot would be 0.0.0-HIJKLMNOP.

IIRC, the command we wanted was changeset pre snapshot <tag>. It would set all the versions to 0.0.0-tag-hash and update that in all the dependents, publish all the packages to the dist tag that was specified and then undo the changes.

Hey, If no one has taken this issue yet. Can I pick it up?

I did some initial implementation https://github.com/atlassian/changesets/tree/issue/137-snapshot-release. It is not ready for review yet, I am yet to wire up the publish step.

Thanks,

I did not work on it yet, so I don't have objections.

@ajaymathur

That would be great @ajaymathur!!

@ajaymathur

<3 Thanks @ajaymathur

Can the snapshot command be used for something like publishing canary releases for every PR/commit merged into master? Or is it for a different use case?

Yes, I think this is one of the use cases. This is what I want to use it for.

Great, looking forward to test it out 🙌

At the moment, we're still using lerna to publish canary releases but we hope to not need that anymore :)

lerna publish --exact --dist-tag canary --canary --preid canary --yes --force-publish \"*\"

[UPDATE]

The change corresponding to this issue is done in #359.

Release in pending in PR: #375

We can close the issue once the PR #375 is merged and a new version is released.

I think snapshot implemented as is is great for canary releases, but it doesn't address the issue with pre mode, which requires you to commit package.json in order to calculate the next pre release number. It makes the process of making a regular release really cumbersome because I need to hard reset all pre release commits first in order to get rid of them in the commit history. ( I don't want prerelease commits to show up in the master branch)

Can we extend the snapshot to support pre mode? that is 1. bump package version normally according to changesets instead of using 0.0.0 2. append the version with tag and timestamp instead of a linearly increasing integer

For example, suppose I have pkg-a at version 1.0.0 and there is a patch changeset for it. I should get 1.0.1-next.[timestamp1] instead of 1.0.1-next.0 after the following commands:

yarn changeset pre next
yarn changeset version

I should not need to commit the package.json after the first rerelease and when I do another prerelease, I should get 1.0.1-next.[a-different-timestamp].

Making snapshot work with pre-mode is definitely something that we'd like to support. I don't quite understand though why the versioning scheme should be different than for non-premode snapshots. Could you elaborate on this one? From what I understand the problem is that premode is just somewhat ignoring snapshot now and thus regular prerelease versions are generated, but that is probably just an oversight and should be quite an easy fix to make snapshots take precedence.

Either way - could you open a new issue in which we could discuss this further? I'm closing this as the original feature request has been implemented, a new issue will allow us to better focus at the issue you are experiencing right now.

Done. #381
It might be helpful to replace prerelease with canary release in the issue title because people may confuse it with the prerelease mode, which this issue is not about, IIUC.

Navigation Menu

Repository navigation

Releasing prerelease versions without modifying package.json files #327

Affected Packages

Problem

Proposed solution

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Releasing prerelease versions without modifying package.json files #327

Description

Affected Packages

Problem

Proposed solution

Activity

Andarist commented on Apr 16, 2020

zkochan commented on Apr 16, 2020

Andarist commented on Apr 16, 2020

zkochan commented on Apr 16, 2020

Andarist commented on Apr 16, 2020

zkochan commented on Apr 16, 2020

Andarist commented on Apr 16, 2020

emmatown commented on Apr 16, 2020

ajaymathur commented on May 3, 2020

zkochan commented on May 3, 2020

emmatown commented on May 4, 2020

Noviny commented on May 4, 2020

emmenko commented on May 11, 2020

zkochan commented on May 11, 2020

emmenko commented on May 11, 2020

ajaymathur commented on May 24, 2020

Feiyang1 commented on May 29, 2020

Andarist commented on May 31, 2020

Feiyang1 commented on May 31, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions