Release 1.15.0

[pavolloffay]

Tracking issue for release 1.15.0. The last release (1.14.0) was done on 2nd September.

We will need UI release (1.5.0). @everett980 could you please release it?

@jaegertracing/jaeger-maintainers please comment which PRs/issues should be resolved before releasing the new version.

It would be nice to get it following PRs:

• Common TLS config Add common TLS configuration #1838
• Collector tags Support collector tags, similar to agent tags #1854
• Duplicate tags WIP: Add Duplicate Tags Policy to Reporter #1788
• Agent reporter queue Place a queue infront of agent reporter to provide some resiliency #1733

[everett980]

@pavolloffay I intend on releasing 1.5.0 of the UI next week. I'm hoping to fit in one more Google Analytics metric and then dog food it internally for a day or two in case of explosions.

[pavolloffay]

I would like to block the release until #1858 is fixed.

[yurishkuro]

@pavolloffay @objectiser @jpkrohling I think we should introduce the process of using Milestones to track issues for the release instead of a tracking ticket, because otherwise when someone looks at a closed PR/issue, it's difficult to say if it has been released or not. A part of the release process would be to go through all issues listed in the changelog for the release and attach them to the corresponding milestone if they are not attached yet.

[objectiser]

Sounds good - if we also categorise them at the same time, bug, feature request, breaking change, etc we might be able to auto-generate a more accurate changelog?

[pavolloffay]

I find it useful what you are proposing but it adds burden. Do you want to label PRs and issues? This could have been done at merge time, alongside with polishing PR title and commit message.

I believe most people look at the changelog when trying to figure out what PRs made it in.

We could also add this link to each version to show which commits made it in. It's easy to add and maintain. v1.14.0...master - the unreleased would compare the latest version against master and a released version would compare against the previously released version.

Sounds good - if we also categorise them at the same time, bug, feature request, breaking change, etc we might be able to auto-generate a more accurate changelog?

There are already defined labels for changelog https://github.com/jaegertracing/jaeger/labels and make target to generate the changelong. However we do not use them during the changelog generation. We need to define a process around merging PRs - perhaps something in https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md

[yurishkuro]

Issue: new prometheus client not building on windows, need to investigate

https://travis-ci.org/jaegertracing/jaeger/jobs/608904003

CGO_ENABLED=0 installsuffix=cgo go build -o ./cmd/agent/agent-windows -ldflags "-X github.com/jaegertracing/jaeger/pkg/version.commitSHA=da16556d3d93dc768f852fec770d374a04485488 -X github.com/jaegertracing/jaeger/pkg/version.latestVersion=v1.15.0 -X github.com/jaegertracing/jaeger/pkg/version.date=2019-11-07T19:56:39Z" ./cmd/agent/main.go
# github.com/jaegertracing/jaeger/vendor/github.com/prometheus/client_golang/prometheus
vendor/github.com/prometheus/client_golang/prometheus/process_collector_windows.go:78:9: assignment mismatch: 2 variables but "github.com/jaegertracing/jaeger/vendor/golang.org/x/sys/windows".GetCurrentProcess returns 1 values

[yurishkuro]

prometheus client seems to depend on a later version of x/sys than Jaeger, trying to upgrade Jaeger

[yurishkuro]

I find it useful what you are proposing but it adds burden.

We already book these tracking issues for releases, is it really much more burden?

I would only tag PRs, not issues, e.g. once the changelog is prepared, go through all PRs and attach them to the milestone (usually it's not that many). Perhaps we could even have a bot that would do that automatically.

I agree that you could get the same information from commit history, but it's much more of a hassle compared to having the release # show up right in the PR screen.

[yurishkuro]

Just did it for last release, it took about 3min to tag the PRs.

https://github.com/jaegertracing/jaeger/milestone/7

[pavolloffay]

We already book these tracking issues for releases, is it really much more burden?

The issues listed in the release tracing ticket like this one are just a subset of issues in a release. These issues are listed here to block the release.

I am fine with using the milestones we just need to document it. Note that 1.15 was not a big release so doing it at release time wasn't that painful.

[yurishkuro]

Documentation released.