Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 1.15.0 #1877

Closed
4 tasks
pavolloffay opened this issue Oct 25, 2019 · 11 comments
Closed
4 tasks

Release 1.15.0 #1877

pavolloffay opened this issue Oct 25, 2019 · 11 comments

Comments

@pavolloffay
Copy link
Member

pavolloffay commented Oct 25, 2019

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:

@pavolloffay pavolloffay pinned this issue Oct 25, 2019
@everett980
Copy link
Contributor

@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
Copy link
Member Author

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

@yurishkuro
Copy link
Member

@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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member

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

@yurishkuro
Copy link
Member

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
Copy link
Member

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

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

@pavolloffay
Copy link
Member Author

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
Copy link
Member

Documentation released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants