Can we get semver releases?

[bufdev]

Would be helpful

[mwitkow]

Yeah, I was thinking about this.

Any guides on to how to automate it? Publishing and releases on github?

Also, any tips on automatic detection of api breaking changs? https://github.com/bradleyfalzon/apicompat for example?

[sagikazarmark]

For a start I think it would be enough to start versioning. Pushing git tags is already automated enough. You can manually create so called releases as well if you want, but it's not necessary to use tags with projects like Glide.

As for API breaking changes: I would say it's the developer's responsibility to take care of it. If you think the library is not mature enough and there are likely to be breaking changes introduced, tag an MJZ version (eg. 0.1.0). Between MJZ versions you are allowed to break the API, as soon as you hit 1.0 you need a new major version for that.

Versioning combined with a changelog should be good enough IMO.

[AlekSi]

Please give us SemVer tags, that's enough for the start.

[mwitkow]

@AlekSi @sagikazarmark

I'd be happy to provide semver releases. But it would probably be worthwhile somehow making them follow the grpc-go versioning
https://github.com/grpc/grpc-go/releases
For example, the metadata changes hit this library hard, and that was a minor.

It seems they follow a wider gRPC versioning scheme, with minors breaking API compatibility, and majors breaking wire compatibility.

Any proposals as to how to structure the semver for this project?

@dfawley @menghanl as gRPC-Go devs to potentially weigh in.

[dfawley]

It seems they follow a wider gRPC versioning scheme, with minors breaking API compatibility, and majors breaking wire compatibility.

Correct. For all gRPC repos, releases are performed on a schedule, and are not tied to any features or API changes. We (grpc-go devs) aren't in a position to change this. However, we will not port non-backward-compatible API changes to patch (dot-dot) releases: only bug fixes or small but important new features will be ported.

IMO your versioning need not match ours; you just need to make sure it's clear what versions of gRPC are compatible with what versions of this repo. I.e. every gRPC release, list that release as a compatible version -- unless it isn't, in which case create a new version to support it (probably just a patch release if it doesn't introduce any new features).

Related: is the current way we're announcing releases (and their API changes) on grpc-go sufficient for your needs?

[achew22]

@dfawley Is there a mailing list for grpc-go announcement that one could subscribe to?

[dfawley]

We send all our announcements for grpc-go to the grpc-io forums, including releases.

[ofpiyush]

Proposal:

Major and minor version same as grpc-go. Patches are independent.

[RouL]

@ofpiyush Don't wanna offend you, but I for my part would prefer SemVer over that.

[ofpiyush]

Sure! now we have two proposals, can we vote with thumbs up and downs to reach consensus by some date X.

I don't necessarily care what versioning system this repo follows as long as it follows something and has tagged releases.

Does that sound ok to you @mwitkow?

[domgreen]

Have added an initial release at v1.0.0.

We are not currently in the same release cycle as the prom project but would like to think that we should start to align big changes with them if this is possible e.g. if we changed all the package names would be good to try and co-ordinate across both projects.