Comment 9 for bug 1594794

It's even more complicated, and while I've thought about it a bit, I can't say I've come up with any solution that I love. In the ubuntu-image case we have three or four "version domains".

* The Python version as you'd set it in setup.py's setup(version=) key.

* The version you see printed when you run `ubuntu-image --version`

* The debian/changelog version in several branches (e.g. stable yakkety branch and master)

* The version in snapcraft.yaml

Where it gets complicated is twofold: you'd like to set the base version in only one place. If you have to set it in multiple places, it's inevitable that you'll miss one and do a broken release. But worse, the exact version strings for each of the above domains may not be identical. Yes, the "base version" will be the same, e.g. 0.8, but you'd have something like:

* 0.8 for the Python-level versions
* e.g. 0.8+16.10ubuntu1 for the yakkety release or 0.8+17.04ubuntu1 for the zesty version
* 0.8+real1 for the snap version

What I currently do is set the version string in the d/changelog file, and then the setup.py digs it out of there (via python3-debian) and uses that to construct the Python-level version string. It puts that in a ubuntu_image/version.txt file, which the setup.py and the program's main() uses to give the Python-level version.

But I still have to manually change the snapcraft.yaml file.

So I'm down to two things to change for every release, which is an improvement, but not fantastic. It's not snapcraft's job to solve all of these, but I do think that if I had a way to invoke snapcraft with a version string placeholder, I could get one process to generate consistent version numbers across all the distribution channels.