Versioning guide - Githubissues

Clever / dev-handbook

A guide to the processes, conventions, and philosophies of the Clever dev team.

Apache License 2.0

63 stars 9 forks source link

Versioning guide #31

Open jonahkagan opened 10 years ago

jonahkagan commented 10 years ago

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 commented 10 years ago

@Clever/engineers your thoughts?

rgarcia commented 10 years ago

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 commented 9 years ago

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 commented 9 years ago

+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.

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
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 commented 9 years ago

Benefit is mitigating confusion/broken builds

azylman commented 9 years ago

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

nathanleiby commented 9 years ago

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

nathanleiby commented 9 years ago

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

azylman commented 9 years ago

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

nathanleiby commented 9 years ago

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 commented 9 years ago

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

agclever commented 9 years ago

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.