3 ms·
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 t
by 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 agoIt'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!