Version numbers for packaging?

[cTurtle98]

My friend and I are working on making a unit file and packaging for debian to make running your script in a proxmox ct easier. Can you add version numbers / release tags for us to use or should we just make up numbers.

[authrequest]

You guys are welcome to just make up numbers. But that sounds fun, I wouldn't mind running a ct myself

[DerVerrater]

Hey hey. I'm the friend working on nonsense.

I've learned that Debian's Go Packaging team will use 0.0~git<YYYYMMDD>.<commitsha1> as the version. This way the lexical sort works for dpkg to know if there's an upgrade or downgrade, and the commit hash is there for a human to go find the source if they need to. This is a workable solution for my needs. If you don't care to keep up with tagging release commits, then that's totally cool.

[authrequest]

Yeah let’s do it! Would be awesome to improve this so it’s more optimized.

[authrequest]

Hey hey. I'm the friend working on nonsense.

I've learned that Debian's Go Packaging team will use 0.0~git<YYYYMMDD>.<commitsha1> as the version. This way the lexical sort works for dpkg to know if there's an upgrade or downgrade, and the commit hash is there for a human to go find the source if they need to. This is a workable solution for my needs. If you don't care to keep up with tagging release commits, then that's totally cool.

I have never dont tagging release commits, How do I create the structure you proposed?

[DerVerrater]

Tag a commit with git tag <version number>, or your favorite IDE's graphical equivalent. The pattern for the version number can really be whatever you want, but I'd recommend either Semantic Versioning or Calendar Versioning.

The important part is that you stay consistent through the lifetime of a project.