Versioning guide

[jonahkagan]

Should cover:

• why version?
• semver!!!
• bump version each time you deploy
• tips by language (e.g. for node, use npm version)

Questions:

• Should we dictate a convention about making separate commits for a version bump?
• Should this be part of the git guide? On one hand, it is part of the workflow. On the other hand, it has to do more with deploying than source control.

[jonahkagan]

@Clever/engineers your thoughts?

[rgarcia]

• I lean towards not dictating this, unless you see a significant benefit. I can think of some downsides
• I think it should be part of the git guide for now as a step to consider when making a change on a library, e.g. "describe/release your change by modifying a changelog and/or bumping a version (if these exist)." The alternative would be to assign maintainers to every repo who are in charge of releasing changes, which seems sub-optimal.

[MaerF0x0]

I think it'd be great to revive this. Frustrating to merge to master and come back after expected build time only to find NPM/Docker deploy failed due to version collisions.

[nathanleiby]

+1 to documenting this and having a process.

In order to make this more robust/automated, I'm highly in favor of Drone auto-bumping the patch version every time merge to master happens. It's safer now that we run Docker images, because consumers of the NPM package won't easily be broken by an (mistakenly) incompatible patch version.

1. until the consumer of your NPM package builds a new docker image, it won't affect deploys -- they'll keep deploying the latest image built
2. even if you've built a new docker image and the updated NPM package is for some reason incompatible, you can always deploy a prior docker image, with the older version of the NPM package

[nathanleiby]

Benefit is mitigating confusion/broken builds

[azylman]

But auto-bumping the patch version would not be following semver, which seems like a significant downside to me

[nathanleiby]

can you clarify why not following? (e.g. some changes shouldn't be patches. OR might publish non-patch as patch)

[nathanleiby]

Another option: change drone logic. if NPM publish fails, don't fail the build. still build docker image

[azylman]

Not all changes are patches - some are minor and some are major, so auto-patching is going to break semver

[nathanleiby]

My thought would be that eng is responsible for specifically changing the package.json for minor/major updates ONLY, before merging.

But true, if it's automatic, someone will probably forget and eventually a minor/major change will mistakenly get automatically published as a patch version.

[MaerF0x0]

Yeah I agree with @azylman 's sentiment against auto touching the version.

[agclever]

FWIW, I prefer doing a version bump in the PR and not post PR. I don't it should have any particular side effects but not sure. Reason being that it seems natural include version bumps with any change. Also ensures that we can review that the version is being bumped correctly.