Repository navigation
Use timestamp to create versions in prerelease mode, so I don't need to commit package.json #381
Description
Affected Packages
@changesets/cli version
Problem
Currently after releasing a prerelease in the prerelease mode, changeset requires you to commit package.json in order to calculate the next prerelease number. It makes the process of making a regular release cumbersome because I need to hard reset all prerelease 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).
The recently implemented snapshot flag doesn't solve the problem, because it always uses 0.0.0, while I'd like to apply version bumps normally as we do today in the prerelease mode.
I think it is important to use the actual version instead of 0.0.0 in the prereleases which is different than the canary releases where 0.0.0 works fine, because I want to communicate my intention of the next release types to developers.
Proposed solution
- bump package version normally as we do today
- 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].
Activity
Andarist commentedon May 31, 2020
I believe that part of the underlying philosophy of the maintainers here is to provide a rather opinionated set of options. It's really hard to satisfy all possible ways in which people would like to use a project like this in the core - we need to avoid feature creep to be able to reason about the internals and provide opinionated guidance for newcomers.
That being said - I'm not trying to dismiss your request right away. I would very much to like understand the use case, motivation, and everything behind it.
Why this would be preferable to you?
You would still want to have releases being published "on demand" (like for regular and pre-releases - in opposite to automatic for which
snapshotwas kinda designed)?Isn't changelog enough? I believe it should contain the necessary info about your intent. I understand though that this is probably not ideal.
If you want to have those releases "on demand" - why? Have them in your history seems really important to me, as a consumer of packages. I often track changes through the git history and having those "checkpoints" in the git history is really useful for me (as a consumer). I assume that you are OK with regular releases having those versioning commits assiociated with them in the git history. Why do you want to treat on-demand prereleases differently?
What problem do you see with linearly increasing integer?
Feiyang1 commentedon May 31, 2020
Correct, but only for pre-releases.
Wouldn't the changelog have version
0.0.0-timestamp? It feels really weird to have, for example,0.0.0-timestampbetween1.0.0and1.1.0in the changelog.How developers get to the changelog is another problem. We use a
releasebranch to stage the snapshot ofmasterevery Tuesday while the development continues inmaster, so the changelog will be committed to thereleasebranch. In order to view this prerelease changelog, consumers would come to the repo and need to know that they need to switch to thereleasebranch. It is a lot of friction that diminishes its usefulness.In addition to that, I don't want prereleases to end up in the changelog at all, because most of the time they just repeat the same thing from the regular release. The problem becomes worse as you do more prereleases.
I can already work around it by not committing changelogs in the pre mode today, but package.json is required to be committed, which is the problem.
Yes, I want the versioning commits with regular release, but
You are probably right that it's useful to have them in the history, but it would be really nice to allow people to opt out. Just like we don't have to commit changelogs, we shouldn't be forced to commit
package.json.I have no problem with it as long as it doesn't require me to commit
package.jsons. The problem is that the current implementation relies onpackage.jsons to calculate the next integer, so I have to commit them after every prerelease.I don't think this proposal is a potential feature creep, because we just use timestamps instead of integers, which provides a little bit more flexibility without fundamentally changing how things work today.
emmatown commentedon May 31, 2020
I don't think this behavior makes sense in Changesets' prerelease mode because the model of the prerelease mode is fundamentally stateful and that state exists in the
package.jsons andpre.json. I think it makes sense with the snapshot release mode but with an experimental option(as in #185 (comment)) to enable the behavior of using the calculated version rather than0.0.0. I suspect this would likely stay there for a long time because this behavior inherently has a problem(#359 (comment)), that problem may not be a concern for you or other people who want this behavior but I don't feel comfortable making that the default without fully understanding the problems.Feiyang1 commentedon Jun 1, 2020
That will work for me (using an experimental flag).
That said, IIUC, the only reason
package.jsons are part of the state is thatchangesetneeds them to calculate the next prerelease version. It seems to me that they don't have to be part of the state if we can generate unique prerelease versions without them, e.g. using commit hash or timestamp. Am I missing something?feat: prerelease channels (branch-based, no committed prerelease vers…