Release schedule

[jpkrohling]

In the past, we've been releasing Jaeger in a sort of "on-demand" fashion. This has resulted in two releases this year, which reflects the number of new features and bug fixes we worked on so far. However, there were quite a few changes to the dependencies we consume, some of them fixing security problems. In order to provide timely fixes to the security problems affecting our dependencies, I would like to suggest adopting a fixed release schedule, like "every first Wednesday of the month". Having frequent releases also helps make sure our release process is up to date, both in terms of automation and in terms of documentation.

If the maintainers are on board with this idea, I'll ask @yurishkuro to add this to our community calendar and will change the readme to reflect this. I'll also work on assigning releases to maintainers so that we know who's responsible for which release.

@jaegertracing/jaeger-maintainers, please add +1/-1 to this idea.
Non-maintainers, add any other reaction you feel appropriate :-)

[pavolloffay]

+1 for a long time we wanted to release Jaeger every month, however that almost never happened and it drifted to roughly every two months.

The biggest issue was always to find resources/maintainer to cut the release. If we move to a fixed date we should resolve this by clear ownership of the task.

[jkowall]

I think monthly is good, but maybe overkill for some months. It's hard to say this is a good idea all the time IMO. Then again I am not a maintainer.

I always notice that the releases are kind of ad hoc and there is no owner from the maintainers. Maybe we have a maintainer to focus on releases, CI/CD, and other elements to help offload this? Just an idea. Do we have the release process documented? Happy to step up to learn to make this happen, but then again I am not a maintainer :)

[jpkrohling]

The release process is documented in the release.md at the root of the repositories. I think we should really rotate the responsibilities, for several reasons. First, it's not "fun" work, engineers typically don't like doing releases. Second, rotating ensure we have proper documentation in place.

If you can offer some engineering help, I would gladly accept it to triage and work on dependency bumps for the UI :-)

[joe-elliott]

I think I get enough "fun" work from Tempo :). I can't sign up to do every release, but I don't mind taking this more often then others. It would be a way I could contribute to Jaeger when I'm having issues finding other avenues.

[albertteoh]

+1
I think other minor benefits include:

• a smaller set of changes for maintainers to curate
• exercises the release process more frequently to iron out issues early instead of accumulating them

[kevinearls]

Agreed, I think regular releases would definitely be a good thing.

[joe-elliott]

Do we think most releases will just be patch releases with updated dependencies and a few small changes? I'm on board with this idea if we think we will have the content to make the releases worth it. I think we have enough maintainers that the rotation will be fairly easy to keep up with.

[albertteoh]

I think this is a fair point, do we always cut a release as long as there are > 0 relevant changes to report in release notes? Or is there a threshold of changes that makes it more worthwhile to cut a new release?

[jpkrohling]

I think we can establish a policy using this point. If we only have version bumps (UI or backend), we bump the patch portion of the version. If we have at least one new feature (again, UI or backend), it's a minor. If we don't get commits at all (huh?), no release for the month.

[joe-elliott]

+1 ing the original suggestion of a regular cadence of releases.

[yurishkuro]

-1 to forced monthly releases.
+1 to documented maintainer rotation (which we already discussed and agreed to informally in the past).

In 2020 we released 5 times, v1.17 - v1.21. What problem are we trying to solve by more frequent releases? Who are the users asking for more frequent releases & why?

[jpkrohling]

What we release isn't only our own code, it's the entire web of dependencies we use, such as the ones from the UI, the backend, and even the base images for the containers. Not doing a release for a few months means that we have a high risk of being exposed to a CVE that is being actively exploited, caused by a dependency of a dependency of ours.

Right now, for instance, there's a vulnerability affecting Go's archive/zip that could potentially bring down any Go application that uses that package. Our (Red Hat) security team assessed this as a low risk for Jaeger, as nothing in our dependency chain uses it, but if we used it and waited a few months to release a new version because we ourselves do not have any new features for our users, Jaeger installations would be sitting there vulnerable for months.

Would it be OK to have a patch release if we get at least one version bump in the given month, from either the UI, backend, toolchain, or base images? If we get new features, we can decide to release a new minor.

[jpkrohling]

We have 3 maintainer votes for the monthly releases and one against. We also have one community vote for the monthly releases (@kevinearls, Red Hat).

We do not need to decide right now, but I would like to keep the discussion happening until we have a consensus. Should we schedule some time to talk about this during a bi-weekly call?

I believe we have enough for 1.24, to be released on July 7th (first Wed of July), so, we might not need to have a decision before 1.25.