axllent
Use go.mod-compliant version tags
Mailpit currently tags releases with strings like 1.2.3. Unfortunately, go.mod requires version tags to be prefixed with a v, e.g. v1.2.3.
Could you switch to this way of version tagging? If you do, the mailpit entry in the go.mod wouldn't look like
github.com/axllent/mailpit v0.0.0-20221015230430-ea12a1ee566e
but like:
github.com/axllent/mailpit v1.2.5
which makes it much easier to see which version you're building against.
I'm interested in how you are using this (as in for what purpose you are importing Mailpit), as Mailpit was never designed to be an importable library, but rather a stand-alone application. The application uses and relies on semantic versioning (which v<tag> is not).
To change this would be a fairly major change to all aspects of the release/build/update/docker process so I need to understand the context better before I can consider this further.
This is strongly related to https://github.com/axllent/mailpit/issues/21
For convenience I don't define e.g. apiv1.MessagesResult myself but use it directly from the (imported) mailpit package.
I know that many project struggle with the fact that semantic versioning does not involve a leading v whereas go modules requires them.
I assume your answer to this issue relies on your answer to https://github.com/axllent/mailpit/issues/21. If you don't want any code to ever be imported from this repository, you probably don't want to change the tags, I understand that.
Just for the record, it is not necessarily that I don't want anyone importing stuff from this project (after all the intention is for it to be a useful app to as many as possible), it just was never my goal when I wrote Mailpit. It is an application, not so much a library - I'm trying to understand your use-case for using parts of it as a library, and whether yours is something that is a rather unique situation, or something that is going to come up more regularly.
In theory I possibly could just switch to using v<semver> without too many consequences, though I'm not overly keen on the idea of just switching simply just to make a go.mod a bit more readable.
I guess additionally tagging the versions using v<semver> is not an option either, is it?
Let me just add that making "a go.mod a bit more readable" is a bit of an understatement IMO. When you read v0.0.0-20221015230430-ea12a1ee566e you basically must visit GitHub to find out which version that could be (and even then it's not trivial).
Fair point. When I release the next version I'll attempt the v tag prefix (tags and releases are directly linked) - if that works as it should then I'll stick with that. If it doesn't work I'll need to roll back to the plain semver releases (so no promises). It needs some internal testing first, and I'm away for the remainder of this week, so it'll likely be over the weekend :+1:
@alfa-alex I've just released v1.2.6 which should address the go.mod-compliant version tags - which appears to work correctly with the self updater, release process, and docker versioning. Please can you test if this solves the go.mod versioning issue? Thanks.
It does and helps me a lot. Thank you!
The only downside I observed is that it also changed the image tags on Docker Hub (now also having the v prefix). I am actually okay with this (already changed the tag in my docker compose file), but it seems a bit non-standard to me, so it might surprise future users. However, I'm afraid this is caused by your build process and cannot be worked around easily!?
I'm glad it helps. I'm sure there is a way to "strip out" the "v" prefix in the version tag for the docker build, but whilst I realise that 1.2.3 is cleaner than v1.2.3, many docker containers use a variety of tagging formats including 1.2.3, 1.2.3-<timestamp> 1.2.3.<hash>, alpine-1.2.3, 1.2.3-alpine etc. The most common tag used is latest which remains the same, so rather than complicate the docker build I'll just leave it as-is as it'll remain consistent with the git tags.
Thanks for the feedback though!