Skip to content

Update transport version docs #133862

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.

Sign up for GitHub

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

Merged
rjernst merged 7 commits into from
Sep 11, 2025
Merged

Update transport version docs #133862

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
f576267
Update TV docs
JVerwolf Aug 29, 2025
4ef84a4
Update
rjernst Sep 9, 2025
ee77afb
Merge branch 'main' into transport/update-docs
rjernst Sep 9, 2025
04335d0
feedback
rjernst Sep 10, 2025
29f2aa7
more feedback
rjernst Sep 11, 2025
bc7c9ac
iter
rjernst Sep 11, 2025
482a031
more feedback
rjernst Sep 11, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion docs/internal/Versioning.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,21 @@ In order to ensure consistency and robustness, all new `TransportVersion`s
must first be created in the `main` branch and then backported to the relevant
release branches.

### Internal state files

The Elasticsearch server jar contains resource files representing each
transport version. These files are loaded at runtime to construct
`TransportVersion` instances. Since each transport version has its own file
they can be backported without conflict.

Additional resource files represent the latest transport version known on
each release branch. If two transport versions are added at the same time,
there will be a conflict in these internal state files, forcing one to be
regenerated to resolve the conflict before merging to `main`.

All of these internal state files are managed by gradle tasks; they should
not be edited directly.
Copy link
Contributor

@prdoyle prdoyle Sep 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is perfect. It's exactly what I had in mind.


_Elastic developers_ - please see corresponding documentation for Serverless
on creating transport versions for Serverless changes.

Expand Down Expand Up @@ -95,7 +110,7 @@ needed to backport to `8.19` you would run (in `main`):
./gradlew generateTransportVersion --name=my_tv --backport-branches=9.1,8.19
Copy link
Contributor

@prdoyle prdoyle Sep 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the value of making backport-branches the ultimate authority on backports; but also, in the specific user story you're describing here, that's counterproductive and error prone. (For example, suppose they failed to notice that 9.0 should also have been included.)

As a user, I'd like to say something like --add-backport-branches=8.19, or --backport-branches=+8.19, and know that it's not going to nuke any existing ones. (FWIW this is also idempotent.)

Copy link
Member

@rjernst rjernst Sep 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a fair point, but I would like to start without this, and add it in the future (it's a bit of complexity to the task implementation). The vast majority of the time developers can just let CI regenerate the transport version based on version labels.

Copy link
Contributor

@prdoyle prdoyle Sep 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me!


In the above case CI will not know what transport version name to update, so you
must update the transport version manually. After merging the updated transport
must run the generate task again as described. After merging the updated transport
version it will need to be backported to all the applicable branches.

### Resolving merge conflicts
Expand Down