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

Proposal: combine backend and UI release versioning and release notes #5323

Closed
yurishkuro opened this issue Apr 3, 2024 · 7 comments · Fixed by #5405
Closed

Proposal: combine backend and UI release versioning and release notes #5323

yurishkuro opened this issue Apr 3, 2024 · 7 comments · Fixed by #5405

Comments

@yurishkuro
Copy link
Member

Today our release process is split into three phases: UI, backend, and the docs:

  • UI: has its own release version numbering; and its own changelog. The value of its own independent version is dubious - it gives a place to publish the release artifacts, but if say there is a bug fix / patch to the UI, we'd still need a new patch for the backend version as well.
  • Backend: different version numbering, its own changelog that includes UI changelog by reference only
  • The docs: same versioning as the backend, blocks on successful publishing of Docker images

Proposal:

  • Adopt the same release numbering from the backend as the only version, since this is how users primarily use Jaeger versions
    • The UI version is currently behind so we can safely pull it forward to match the backend/main version
  • Incorporate UI release notes into the main release notes, such that jaeger/releases/vX.Y.Z becomes a single place to see "what's in the new release".
    • We already have a script that can extract release notes from a changelog, so it should be pretty straightforward to pull UI notes and add them to the backend changelog
    • The UI release notes will still be done the same way as today
@jkowall
Copy link
Contributor

jkowall commented Apr 3, 2024

We used to pin the UI more, but we don't seem to do that very commonly these days. Otherwise, I don't see the point of having them separate.

The proposal makes sense to me. The question is does this change on Jaeger v2 when things already merge more so than they are now? Should we bother making the change now when we'll have other changes?

@yurishkuro
Copy link
Member Author

I don't think v2 will have much impact on this side of the release process. We're still going to have three separate parts, : UI, backend, and docs.

@yurishkuro
Copy link
Member Author

What do you mean by "we used to pin UI more"?

@jkowall
Copy link
Contributor

jkowall commented Apr 3, 2024

Is there any advantage to having the build processes integrated better to make releases easier? I guess with the different languages and CI it's probably not worth doing the work.

What do you mean by "we used to pin UI more"?
We used to keep the UI the same sometimes and not release it every time.

@yurishkuro
Copy link
Member Author

The release process would've been easier if we had a monorepo.

Yeah, we may have reused ui versions, but if we keep up to date with the dependencies then there are always changes.

@albertteoh
Copy link
Contributor

The release process would've been easier if we had a monorepo.

I think consolidating release versions and release notes is a good idea in general because of the tight coupling between the two repos.

Curious, what are the benefits of keeping jaeger ui in its own separate repo given both components are released in tandem?

@yurishkuro
Copy link
Member Author

Monorepo requires more advanced tooling, especially for CI - imagine making a UI change and having to wait for 20 workflow that test the backend

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

Successfully merging a pull request may close this issue.

3 participants