Project versioning or abstract versioning

[maticzav]

Hey 👋,

I would love to get some feedback on what your preferred way of versioning is. To my understanding, there are two major versioning options:

1. we version "in-project" and keep versions in the package.json file of each workspace, or
2. we calculate the current and next version from releases on the go (semantic-release way).

in-project

pros

• no onboarding process (you can just use it with your current setup)
• version can be easily traced in the commits

cons

• versioning step has to be committed to branches
• more difficult to test
• complex flow and a possible need for separation of packages (separate versioning, then PR with a new release, then publishing of packages)

on-the-go

pros

• no commits, only tooling
• more functional
• more easily tested
• more meaningful flow of the publishing (versioning only affects final published packages)

cons

• version has to be 0.0.0-semantha all the time because of yarn workspaces,

this might not be an issue after all

• more difficult to track version in commits

What do you think? 🙂

[rarkins]

My gut feeling is that having to perform commits back to the repo is annoying and adds an extra level of possible failure/state mismatch. Also ideally you would need the least credentials possible, such as no GitHub master commit credentials sitting on CI.

However one challenge/problem with this is that you probably want to support Release Notes either via GitHub's releases feature or a CHANGELOG.md. In theory you could "build" a CHANGELOG.md entry into each npm release without the version being committed to master, but the reality is that npm doesn't provide an easy way to read these, so most people won't.

One other thing to consider: release notes may and often are edited post-release. So that's another downside of bundling a dynamically generated CHANGELOG.md with the npm release.

Making CHANGELOG.md edits as a PR is an interesting concept I hadn't considered before. It's advantage is allowing humans to first edit the auto-generated changelog prior to committing to master. But I wonder if all that human intervention will be welcomed.

By the way, both npmjs as well as GitHub releases support the concept of linking to the "gitRef" dynamically, so "tracking version in commits" is possible that way. Also semantic release does a good job of tagging too, so I never have a problem working out which commit a version refers to.