changelog and release process

[Tobias Schmidt]

Hey everyone,

thanks for the great Software. SoundCloud has been a happy user of mtail for years.

I just found an internal service which uses a mtail version from ~15 months ago. That mtail version has some undesired behavior (e.g. exporting a Prometheus instance label). I saw that this has been fixed in the meantime, but couldn't find any way to check breaking changes. The project also doesn't seem to follow any common release process, all I could find are release candidates for the last year. With over 1000 commits since last year, it's very hard for users to understand what changes have been made or need to be watched out for.

Would it be possible to adopt a proper release and changelog process, so that users can confidently upgrade to newer mtail versions without having to read every single commit?

Thanks a lot,

Tobias

[Jamie Wilkinson]

Thanks for your mail, Tobias!  I'm very glad that Soundcloud is finding mtail useful.

These are good questions and I don't have a great answer for you yet, but thanks for raising them.

I try very hard to not make breaking changes to mtail.  Every tagged release has to pass all the tests, which while not perfect, at least confirm that the language and exports are consistent.  After we pass the rcX candidates and really launch 3.0.0 then there will be a very safe assumption on nonbreaking change, I expect.  But like all these things, we need volunteers to report problems when they happen.

I don't believe that you will have a problem upgrading your mtail to the latest rc tag, because I have high confidence that it does not include breaking changes, but of course I would like to know if you do have any.  Is there any way you could incorporate the latest tag into your release testing so that you don't end up finding a lost instance 15 months later?

I'm not keen on publishing a changelog because that's the purpose of the revision history, IMHO.  But if there's demand, I can try.  Or, appeal to the generosity of volunteers to help.

The releases are proper, already, but I haven't got a good definition of what it I'm trying to reach before tagging 3.0.0.  I can't promise a time bound on doing so, but I should review what's missing and commit to a minimal set of issues to fix before we declare this no longer a release candidate but a "real" release.

Again, thanks for starting the conversation.  What do you think about what I've suggested above?  I'm happy to hear any and all criticism.

--
You received this message because you are subscribed to the Google Groups "mtail-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mtail-users...@googlegroups.com.
To post to this group, send email to mtail...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mtail-users/3621a205-3514-446c-a12e-6784073c49a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jamie Wilkinson]

I've been researching release notes automation and have some good leads on avoiding some manual work for each github release.

We won't be hitting a 3.0.0 proper release until the last few reported bugs are complete.