2 ms·

This is almost as bad as the original article... Just deploy any change to main... don't worry about version numbers unless it matters, even then, just version

This is almost as bad as the original article... Just deploy any change to main... don't worry about version numbers unless it matters, even then, just version your spec, not your application. If it does matter, deploy all changes to your QA environment. Once you're happy (at the end of a sprint or whatever), tag a commit and release that to production. Need a hotfix? Branch off of your tag, do the thing, and tag that commit and merge it to main. There's no reason for "version" files. you can pull your previous version image and compare the SHA hashes for your new version. If they're different, then deploy the new one (heh, maybe you got some security patches from the base image). Otherwise, no reason to deploy -- or if you have zero-downtime deployments, just deploy it anyway and don't worry about comparing hashes or whether or not something changed.

alkonaut 3y ago
Any release I have made whether it's to a package manager or an app store or a windows app etc has had to have not just versions for the product but also some times exact versions for individual files (e.g. Traditional Windows installer apps where screwing up the versioning on even one file is a huge mistake that might prevent the next deployment from working toe to downgrade rules.) I have spent a lot more time in my life on thinking about "versioning schemes" than I have "branching schemes" due to this. E.g. windows files and apps don't have SemVer, just a 4 component version, so you really need to think long and hard about the kind of thing whether 1.0-dev should be 1.0.10 or 1.0.1 in order to sort properly over your 1.0-final and so on. A world where you can just "deploy an image" and know it just replaces your previous one and in general one where you can deploy yourself, to machines you control sounds nice compared to making packages which should work at 10k different users and follow the whims of various stores, package managers and installer systems.
- withinboredom 3y ago
  It's still not any different. Just tag your release in git. No need for versions files. 1.0 matches 1.0 matches 1.0 of all the components. Want to know what version 1.1 is compatible with? You guessed it, 1.1!

alkonaut 3y ago

Any release I have made whether it's to a package manager or an app store or a windows app etc has had to have not just versions for the product but also some times exact versions for individual files (e.g. Traditional Windows installer apps where screwing up the versioning on even one file is a huge mistake that might prevent the next deployment from working toe to downgrade rules.) I have spent a lot more time in my life on thinking about "versioning schemes" than I have "branching schemes" due to this. E.g. windows files and apps don't have SemVer, just a 4 component version, so you really need to think long and hard about the kind of thing whether 1.0-dev should be 1.0.10 or 1.0.1 in order to sort properly over your 1.0-final and so on. A world where you can just "deploy an image" and know it just replaces your previous one and in general one where you can deploy yourself, to machines you control sounds nice compared to making packages which should work at 10k different users and follow the whims of various stores, package managers and installer systems.

withinboredom 3y ago
It's still not any different. Just tag your release in git. No need for versions files. 1.0 matches 1.0 matches 1.0 of all the components. Want to know what version 1.1 is compatible with? You guessed it, 1.1!