chore: Switch to pinned nanoversion strategy - #1069
Conversation
|
Xiang Li (@xli1996) What's the strategy going to be for keeping the nano-version up to date? There are definite advantages of pinning the version wrt stability, but the counter argument is that the pinned component gets hugely out of date and then there is potentially an effort needed to get the components working together again after eg 6 months of being forgotten. |
|
As I understand it, the nano version is automatically updated when there's a successful build. |
|
+1 to what Emma Humber (@ehumber) said. Ismael Juma (@ijuma) thats gr8! Xiang Li (@xli1996) & Ismael Juma (@ijuma) if pinned version doesn't get updated for a while(breaking build/tests etc.), is there a way that SR team/oncall will get notified to take action? |
|
|
what
This PR adds
pinnedNanoVersionsproperty, so that project will try to pin each upstream version update in pom.xml instead of using version range which always selects the latest version.e.g.

[7.3.0, 7.4.0) -> 7.3.0-99 after each build
why
The current git workflow:
That is brought up by Ksql team initially because they want to have better reproducible builds. And with that change, version bumps will only happen when the upstream build is compatible. That means the mater branch will be more stable and reject broken upstream changes.