Support different release emails for v0.x.x releases

[joseph-wakeling-sociomantic]

SemVer rules operate differently for v0.x.x compared to stable major release series: http://semver.org/#spec-item-4

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

Neptune's release emails should reflect this distinction in terms of their claims for API stability and backwards compatibility.

[mathias-baumann-sociomantic]

I'd say this is not only a release tool issue but a neptune issue in general as our documents don't reflect this at all

[joseph-wakeling-sociomantic]

Perhaps useful: what we have in the README of dmxnet: https://github.com/sociomantic-tsunami/dmxnet/#versioning

[mathias-lang-sociomantic]

Perhaps the simplest option would be to not send emails for major == 0 ?

[joseph-wakeling-sociomantic]

Perhaps the simplest option would be to not send emails for major == 0 ?

It should be up to the maintainer whether to send an email or not, neptune-release shouldn't magically special case any particular version.

[mathias-baumann-sociomantic]

Well, version 0 is already special cased such as that the first version would be v0.1.0 ;)-

[joseph-wakeling-sociomantic]

Yes, but that's about basic compatibility with semver, the presence (or absence) of a release email is completely orthogonal to that.

The only special casing here needed here is of the email content.

[joseph-wakeling-sociomantic]

Where are the email texts contained? Happy to at least draft a text.

[leandro-lucarella-sociomantic]

I think we need different templates for different kind of e-mails. For example rc versions should also not recommend everybody to upgrade.

Also, making them configurable could be a good idea too, for now they are hardcoded.

[leandro-lucarella-sociomantic]

Using git to configure it might be a good idea as it already provide a way to override globally and per-repo, which is nice.

[joseph-wakeling-sociomantic]

For example rc versions should also not recommend everybody to upgrade.

Related note: the --pre-release flag of neptune-release seems to auto-impose a -rc.N version number. But with v0.x.y we might well wish to always denote this as pre-release (in GitHub terms), even though it is recommended to always upgrade.

It sounds like rather than a global email, it would be good to have a few different sections contingent on different aspects of the version number:

• description of the kind of release (major/minor/patch, v0.x.y minor, v0.x.y patch)

• description of expectations regarding the kind of changes made (possible breaking changes, new functionality only, non-breaking fixes only...)

  • dependent on the version number, we could maybe special-case the inclusion of the +breaking version extension?

• recommendations for use ("Upgrade at some point in the next ...", "Upgrade as soon as possible", "Test to ensure it works with your project and does not introduce regressions")

  • should all be contingent on the version number alone (e.g. the last would be contingent on the presence of a -rc.N, -beta.N, or -alpha.N)

It might also be a good idea if there is an option to edit the email text before sending, in case the maintainer wants to make small tweaks or add some info.

If this sort of thing sounds good we should probably move discussion over to another repo.

[leandro-lucarella-sociomantic]

But with v0.x.y we might well wish to always denote this as pre-release (in GitHub terms), even though it is recommended to always upgrade.

I think this is redundant. I would say a v0.x.x release is not really a pre-release but a preview release if you wish. Or an immature release.

(major/minor/patch, v0.x.y minor, v0.x.y patch)

Also this seems to be weird, v0.x.y can be also a "major" release in terms of breaking changes. For me it's safer to say that v0.x.y is equivalent to a "major" release rather than a "minor", since you are at a preview, then if it turns out to be backwards compatible you were just lucky.

I'm starting to think this whole message is overkill to be honest. All this is defined in some docs, the release notes could just link to those docs instead of repeat them on every release.

It might also be a good idea if there is an option to edit the email text before sending, in case the maintainer wants to make small tweaks or add some info.

Please create a separate issue for this, there are several related issues to get an editor for a final edit to release notes too, I think there are several places where being able to get an editor for a final touch would be good.

If this sort of thing sounds good we should probably move discussion over to another repo.

I think it should be done in an issue in this very same repo. I think we first need to define in the docs special meaning for releases that are not specified by SemVer (like -rc.X, -alpha.X, -beta.X or v0.x.y "minor" / "patch"). I think there is at least one issue for the pre-releases.