-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Comments
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? |
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. |
What do you mean by "we used to pin UI more"? |
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.
|
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. |
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? |
Monorepo requires more advanced tooling, especially for CI - imagine making a UI change and having to wait for 20 workflow that test the backend |
Today our release process is split into three phases: UI, backend, and the docs:
Proposal:
The text was updated successfully, but these errors were encountered: