Semver

[TillaTheHun0]

We will need to Semver bump Hyper adapters, ports, and apps.

Ideally, this would be an automated process. In order to automate this process, there is a typical strategy used.

First, commit message format is usually standardized. A popular spec for commit message format can be found here.

Once commit messages are standardized, another tool is usually used to inspect the commit messages, since the last marker (usually a git tag). This determines if the version bump will be MAJOR MINOR or PATCH bump.

Finally, a tool takes the new version and will bump manifest files, generate changelogs, and create a new git tag.

So we have:

1. standardize and enforce commit message
2. Inspect commits to determine semver bump
3. perform semver bump, tagging, and changelog gen

There are tools that already enforce and perform the work described above. Some of these tools:

"linting" commit messages: commitlint + pre-commit hook like husky (commitlint via pre-commit hook) 1

Inspecting commit messages, bumping manifests, tag and changelog generation: standard-version or semantic-release 2&3

---

The problem is that these tools are not working with Deno, via skypack. We may be able to replace tools like Husky with just vanilla git pre-commit hooks, but replacing tools like commitlint and standard-version seems like more work. We have some options:

Option 1 - use Node and npm for these tools

each package would have a package.json that contains scripts for running only these tools. Version would be bumped in egg.json and tagged accordingly.

As the Deno ecosystem becomes more mature, we can remove package.json and swap to using native deno tools for doing this. This prevents us from reinventing the wheel and get's us semver releasing more quickly, but adds a dependency on node for both the developer (commit linting must happen at commit time) and CI (bumping, tagging)

Option 2 - use Node and npm for CI tooling, but don't programmatically enforce commit messages

This is similar to option 1, but doesn't use tooling to enforce commit message. maintainers would need to go in on PRs and clean up commit messages prior to merging into main. This is similar to what the deno core team does. Then only CI has a dependency on Node to semver bump an tag.

The extra burden is that maintainers would need to ensure commits are cleaned up, prior to merges to main, which involves rebasing and some "git-fu". I am fine with this, but other core maintainers may not. Regardless, it put's extra diligence on the core team, instead of automating it via a programmatic commit linter.

Option 3 - build these tools on Deno

No dependency on Node or npm. We would copy pasta code where we could from these tools and create our own tooling for enforcing commit message format, inspecting commit messages, bumping and tagging, and generating changelogs.

I believe this would take the most time, but would stay in the Deno ecosystem.

[tripott]

At first glance, I'm leaning toward option 1. Although, on a side note, I am skeptical that an effective changelog could be generated with useful information based on commit messages.

[twilson63]

We should also look at Continuous Delivery practices where commits are not tied to feature releases and are continuously pushed to master, how would automated versioning work then, shouldn't we consider versioning triggering from a github release?

And should commits be able to happen to master without having to bump a version, master should always be deployable so the commit can not break the application, but we should practice continuous delivery of multiple commits to trunk a day and each developer pulling from trunk before pushing their commit. And releases should be controlled via a github release that kicks off automation, right?

I have serious doubts about automating change logs as well, happy to conform to commit messages, but I have yet to meet anyone that has been able to get a reliable formal change log that provides value from commits. We will most likely have to keep a more polished change log in archbee.

I triggered releases to npm via actions on release events, we should be able to read the version number from the git tag and generate the eggs.json file to push nest.land, and the webhook should publish to deno.land. (Right?)

[twilson63]

I think we should consider not having a package.json in a deno lib, this will confuse people thinking it will work with node and it will not be compatible with node

[twilson63]

Lets do some research on some popular deno libs how they automate semver in their packages, I think many of them use github actions on release events.

[twilson63]

Looking through denodrivers the redis project uses this action - https://github.com/keroxp/dink-bot

[TillaTheHun0]

The flow that i've seen work well for libraries is that a new version is tagged and released any time the tip of main changes, not as a result from CI. Then CI inspects commits, bumps version, tags, pushes back to new file/changelogs to main and releases. How that tip goes about being changed is a matter of policy ie. always from PR, from certain contributors, push straight to main, etc.

Personally, I think that if we aren't enforcing commit messages, via something like a pre-commit hook, then we should have to submit a PR, which gives us an opportunity to clean up commits. Pushing straight to a public branch without any sort of pre-checks on commit message format and squashing commits sounds like messy git history bound to happen.

Github releases can be tied to any tag. This is where Core team could create releases to mark notable changes ie. breaking, new features. But otherwise, the code would be continuously delivered and published onto distribution platforms and a changelog continuously appended to, anytime the tip of main changed.

[TillaTheHun0]

Another option that just came to mind:

Use Node and NPM for CI tooling, CI installing tools it needs for semver

Similar to how CI might install tooling to perform certain tasks ie. install node, install yarn, install CLIs, etc. CI would install all the tooling in the CI environment from npm, it needs to semver bump. This means no package.json is in the repo, and we don't have to build out the tooling ourselves.

The most we'd have to build is add a pre-commit hook to lint commit messages, if we wanted to do that.

[TillaTheHun0]

Another benefit of this is that this could be implemented as a github action and tooling centralized instead of duplicated across each repo.

[twilson63]

like the idea of ci tooling living in github actions

[tripott]

sounds good to me.