Request for comments: Switch to full semver versioning starting with the next release

[wneessen]

I was thinking that go-mail has reached a state that I would call "stable", so it might be time to release a v1 at this point and then follow the official semver requirements. I think I will finish up the last two open issues (which one of them might be considered "breaking"), once that is done, there is no pending breaking change.

By following strict semver, this would also mean that any further breaking change would imply a major version bump to v2 and so on.

I am looking for some input/comments/recommendations from people that have done this before and if you think that we're ready for this or if you got any objections.

Maybe @james-d-elliott as maintainer of a big project on Github and a avid contributor to this project has some input here?

Looking forward to your replies.

[james-d-elliott]

I think it's a good idea in general based on the state of the library to make this change, it'll also be good to cross off (one way or another) the potential breaking changes prior to going v1 as it's ideal for implementers if you never have to go v2.

I can't remember if this is relevant to this library but one of the things I have in mind for some of the libraries I maintain (all v0) is to double check any functional options implementations to ensure they give me essentially all of the potential future power I think is necessary to make non breaking additions to the API. You can always add the ellipsis arguments to a function later to do this kind of thing to functions that don't have them, but changing the signature of an existing ellipsis argument would be a breaking change in most instances.

[wneessen]

Thank for your input James.

[...] going v1 as it's ideal for implementers if you never have to go v2.

Can you elaborate a bit more, why you think going to v2 (or higher) would be not recommended? My understanding of semver is, if you have to make breaking changes, you up the major version number to make sure implementors understand that this change would be breaking. What's my oversight here potentially going to v2 or v3 at some point (unlikely to be honest, but who knows)?

[james-d-elliott]

There's no specific oversight. v2, v3, etc. are fine but often involve manual changes (due to breaking changes) by implementers which is what I meant.

It's ideal if that never has to happen but it's very likely unavoidable at some point unless you can predict future requirements, are very lucky, or have an exceptionally well designed architecture.

I agree that it's better to bump major rather than not communicate the fact there is a breaking change.