starred/mailpit

Fork 0

mirror of https://github.com/axllent/mailpit.git synced 2026-04-26 08:45:54 +03:00

[GH-ISSUE #20] Use go.mod-compliant version tags #17

New issue

Closed

opened 2026-03-15 12:07:03 +03:00 by kerem · 8 comments

kerem commented

2026-03-15 12:07:03 +03:00

Owner

Originally created by @alfa-alex on GitHub (Oct 20, 2022).
Original GitHub issue: https://github.com/axllent/mailpit/issues/20

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.

Originally created by @alfa-alex on GitHub (Oct 20, 2022). Original GitHub issue: https://github.com/axllent/mailpit/issues/20 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.

kerem closed this issue

2026-03-15 12:07:08 +03:00

kerem commented

2026-03-15 12:07:15 +03:00

Author

Owner

@axllent commented on GitHub (Oct 20, 2022):

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.

@axllent commented on GitHub (Oct 20, 2022): 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](https://semver.org/#is-v123-a-semantic-version)). 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.

kerem commented

2026-03-15 12:07:20 +03:00

Author

Owner

@alfa-alex commented on GitHub (Oct 21, 2022):

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.

@alfa-alex commented on GitHub (Oct 21, 2022): 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.

kerem commented

2026-03-15 12:07:25 +03:00

Author

Owner

@axllent commented on GitHub (Oct 21, 2022):

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.

@axllent commented on GitHub (Oct 21, 2022): 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.

kerem commented

2026-03-15 12:07:30 +03:00

Author

Owner

@alfa-alex commented on GitHub (Oct 24, 2022):

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).

@alfa-alex commented on GitHub (Oct 24, 2022): 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).

kerem commented

2026-03-15 12:07:35 +03:00

Author

Owner

@axllent commented on GitHub (Oct 24, 2022):

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 👍

@axllent commented on GitHub (Oct 24, 2022): 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:

kerem commented

2026-03-15 12:07:40 +03:00

Author

Owner

@axllent commented on GitHub (Oct 28, 2022):

@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.

@axllent commented on GitHub (Oct 28, 2022): @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.

kerem commented

2026-03-15 12:07:45 +03:00

Author

Owner

@alfa-alex commented on GitHub (Nov 3, 2022):

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!?

@alfa-alex commented on GitHub (Nov 3, 2022): 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!?

kerem commented

2026-03-15 12:07:50 +03:00

Author

Owner

@axllent commented on GitHub (Nov 3, 2022):

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!

@axllent commented on GitHub (Nov 3, 2022): 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!