Command to calculate next version value

[laughedelic]

Hi! I see that auto version return the semantic version bump, but is there a way to get the next (release) version with that bump applied? I think it would be very useful in non-standard release workflows that want to call atomic auto commands instead of relying on the complex ones like shipit.

[hipstersmoothie]

You can run auto shipit --dry-run --quiet and only the new version will be outputed.

[hipstersmoothie]

Really what it comes down to is that the publishing commands (shipit, latest, next, canary) are all heavily integrated with the package manager plugins. These plugins are where auto actually get your version from your project, but all interaction with that version is delegated to the plugins.

The "atomic" command (version, changelog, release) dont interact with the package manager plugins almost at all.

• version => Give the bump
• changelog=> Make a changelog given that bump
• release => Make a release for the last tag

As you can see none of this really requires interaction with the packages all that much. This is where the package manager plugins come in

• version
• changelog
• Package manager plugin (via shipit) or user scripts facilitate a release
• release

[laughedelic]

Thanks! This is a great explanation!

I think I understand now where my confusion comes from. I thought that the last release/version information is normally taken from the git tags, but now I see that for someone coming from the Node.js background the source of truth for versioning is the package manager and its manifest file like package.json.

Okay, so we can document that to calculate a version one needs to run one of the release commands with the --dry-run --quiet flags. Some names are still quite confusing though in my opinion:

• latest gives the next release version, while
• next gives the next release candidate version

Again, I understand that they come from the npm conventions.

[bnigh]

Just came across this, and did not know this was a feature... so looks like these new discussions are working in at least 1 case 😄

Regarding above, @hipstersmoothie , would you be able to clarify a few items:

(1)

Why does the next version come from a command that encompasses the whole release process? This seems counter-intuitive to me. Doesn't the current version command have enough information for calculating the next version?

shipit can make various types of releases (latest, next, canary, and old). It picks which one to create based on where it's run. shipit really just runs other commands under the hood (the commands for latest, next, canary, and old). So the utility in this is that it will give you the version for the appropriate release type.

I would agree that utilizing shipit initially seems a bit counter-intuitive. Could the version incrementing and release type identification logic be combined with auto version to correctly calculate the next version? or does this just become the same as shipit -dq implementation?

A tangential thought:

• perhaps it would be useful to expose the release type identification logic as output of one of the cli commands (or a new one) since users may want to invoke additional logic for different release types outside of hooks (related to use case: Separate local release actions from publishing #1965)

(2)

I think I understand now where my confusion comes from. I thought that the last release/version information is normally taken from the git tags, but now I see that for someone coming from the Node.js background the source of truth for versioning is the package manager and its manifest file like package.json.

My current understanding is slightly different. Since auto initially reads from the tags / release notes, I was thinking the git tags / release notes were the source of truth (and writing to manifest file is side effect required by the package manager).

What does auto view as source of truth - the manifest versions, or the git tags / release notes?

[laughedelic]

@bnigh thanks for bringing this up again. I'm sort of trying to add an extra flag to the release commands as a shortcut to --dry-run --quiet: e.g. auto shipit --version.

I'm curious in @hipstersmoothie's answers to your questions as well. Meanwhile, here are my two cents of understanding from reading the code:

What does auto view as source of truth - the manifest versions, or the git tags / release notes?

I think it depends on the (publishing) plugins you enable. In case of git-tag plugin, git is the only source of information. But if you enable plugins like npm, maven or gradle, they read version value from the manifest (e.g. here). There are two relevant hooks here:

• getPreviousVersion which does what it says
• version which calculates the next (release) version using the previous version and the bump (based on the PRs and labels since the previous version) and then it also creates the tag and/or modifies the manifest and commits it

So the logic of calculating the next version and "setting" it is all in the same hook. It's possible to just get the version out of it if you run that hook with the --dry-run flag, but the hook is not available through the CLI (back to #1965 (comment)).

To make things a bit more complicated: this version hook is used when you create a full release (auto latest or shipit on the main branch), but if you run canary, all the logic for calculating the canary version and publishing is in the canary hook, it doesn't use the version hook.

[bnigh]

@laughedelic

I'm sort of trying to add an extra flag to the release commands as a shortcut

A shortcut seems like should be simple and nice! In conjunction adding the details to docs should help, although admittedly, I'm not sure what would be most discoverable for docs. I'm not sure a user would immediately jump to reading flags to find next version. Like you, my initial thought was the auto version command. Perhaps is non-issue though if users can find via site-wide search.

---

What does auto view as source of truth - the manifest versions, or the git tags / release notes?

Reading through more code, I'm a bit more confused...

I would have thought that auto would treat one of these as source of truth and solely read from that source, but it looks like it reads from both places:

• reads from tags:
  • during auto version and parent commands that invoke it (like auto latest), the semver bump is calculated from either the latest git tag or the latest github release when not using from flag
    • although these are technically different entities, I am treating as equivalent since it a github release requires a git tag
    • see: https://github.com/intuit/auto/blob/b1fcc83b780cbc581f8ead6a1b177af56a2c026f/packages/core/src/auto.ts#L1804...L1807
• reads from manifest
  • as you mentioned:

  • getPreviousVersion which does what it says
  • version which calculates the next (release) version using the previous version and the bump (based on the PRs and labels since the previous version) and then it also creates the tag and/or modifies the manifest and commits it

While ideally the manifest and tags should not be out of sync,

• is it possible for a version hook to write and publish new version to manifest but fail to push tag (or vice-versa)?
  • If so, how would auto behave on next invocation?
  • Would semver bump starting ref (ie: --from field used in auto version) potentially be different than the ref of previous version found from getPreviousVersion hook?

[laughedelic]

For the reference, I just found this old issue with the same feature request: #1490