Compatible with "version update" pushes?

[elliot-nelson]

Is it possible to use this workflow, but also get package.json updates? (so that the version released is reflected in the master branch's package.json).

[mikeal]

That’s what I did originally but found it too noisy, every commit has another commit after it and those lose their signaling value once you are releasing every commit to master.

[elliot-nelson]

What would you recommend with this workflow if you needed to keep two "branches" up to date at once? In that case you wouldn't be able to always bump from the "latest" version.

[mikeal]

You know, I thought these release commits were really important before I was releasing every merge but now I can’t say I see the importance.

Also, the git tag does have the package.json version updated properly, so you have a complete reference in git it just isn’t in master.

[mikeal]

What would you recommend with this workflow if you needed to keep two "branches" up to date at once? In that case you wouldn't be able to always bump from the "latest" version.

That’s a tough one.

First of all, you should be able to setup the releases to run from any branch. The action can be triggered for any branch, if we have code somewhere that assumes master we should update it not to.

You could trigger the action in multiple branches, but you’d have some problems. The strategy for this project is to treat the registry as the source of truth for the “latest” release and that has a one-to-one relationship with the branch you release from. I don’t know how you would coordinate releases from multiple branches on the same npm package since each branch would assume the latest npm release is for their branch, but if you changed the package.json name in each branch it should work just fine.

[elliot-nelson]

Thanks for all the thoughts... it's probably OK if this particular approach isn't for every project.

It seems like it would be cool if you could indicate your version range in package.json, for example, in the scenario where master was v5 and you were also supporting bug fixes only in the stable/v4 branch (perhaps because it supported node v8 or something), then:

// in master:
    "version": "x.x.x"

// in stable/v4:
    "version": "4.x.x"

If package.version contains any x characters, the behavior would change to look for all versions matching that scheme, select the highest, and treat that as the baseline. If you attempted to go outside the range (by checking in a "BREAKING CHANGE!" to stable/v4, producing a major version bump), it could fail with an error (because it's not clear what the expected outcome is to such an action).

I think you could write this, but whether it's worth seeing "npm WARN Invalid version" errors every time you run npm is debatable.

[mikeal]

Interesting approach, I kind of like it. Having a non-compliant version in package.json means you can’t accidentally get this behavior.

I’d take a PR for this. But just a warning if you’re going to work on it, testing this is going to be a lot of work ;) I still haven’t found a reasonable way to test GitHub Actions without just doing a lot of pushes.

[flynneva]

just a comment on sort-of this topic - i am running into this problem now where I am using this action to bump/tag the release, but then a different action to make a "github release" that uses the github api.

all thats missing to make the github release is to know the version number (tag number) to release. i've found other actions that can do this by reading the package.json file and outputting the version to a github actions variable....but it only works if the package.json is up-to-date. see the npm-get-version-action here.

i think a reasonable solution that would solve both of your problems (and mine) is that this action could return the new version number as a variable for other steps in the workflow to use. that way, this action is not by default annoyingly committing to main but an end user could chose to do that themselves using another action.