chore: Switch to pinned nanoversion strategy

[xli1996]

what

This PR adds pinnedNanoVersions property, 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

• better reproducible builds, master/release branch won't follow latest upstream dependency because of version range. Local build dependencies can be traced more easily.
• branch become more stable since it will reject broken changes from upstream.
• version bump commit will be serperated from actual code change so that broken change can be targeted easily.

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.

[ehumber]

@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.

[ijuma]

As I understand it, the nano version is automatically updated when there's a successful build.

[msn-tldr]

+1 to what @ehumber said.

@ijuma thats gr8!

@xli1996 & @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?