+1
Thanks for bringing this and taking care of this.
-Anil.
On 1/3/22, 10:41 AM, "Dan Smith" <dasm...@vmware.com> wrote:
Looking at KnownVersion.java - we did make protocol changes in 1.12.1 and
1.13.2. So, my suggestion would be to keep 1.12.0 and 1.13.1, but dop all the
other patch versions that aren't the latest.
-Dan
________________________________
From: Dan Smith <dasm...@vmware.com>
Sent: Monday, January 3, 2022 10:37 AM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: [DISCUSS] proposal to pare down old-version testing
+1 - this seems reasonable to me. If we do make a protocol change in a
patch, we could potentially keep around an older patch version just in that
specific case, but otherwise I think this makes sense.
-Dan
________________________________
From: Anthony Baker <bak...@vmware.com>
Sent: Thursday, December 23, 2021 8:53 AM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: [DISCUSS] proposal to pare down old-version testing
Interesting data point: 40% of maven central downloads last month were for
version 1.4.0. Of course those numbers can be easily skewed by CI bots, but
still!
@Owen, I think your suggestion nicely improves practicality while
continuing to support strong compatibility. In many cases it’s quite a bit
easier to upgrade the Geode server cluster compared to potentially many, many
client applications. Supporting older client versions gives users time to
upgrade, quicker access to bug fixes, and helps avoids downtime.
+1
Anthony
> On Dec 22, 2021, at 7:13 PM, Owen Nichols <onich...@vmware.com> wrote:
>
> Since adopting our N-2 support policy, the list of released versions in
/settings.gradle has ballooned to over 30 entries [1].
>
> CI tests use this list to confirm that we don’t break rolling upgrade
ability or compatibility with older clients, but some of these tests don’t seem
to scale well: PR#7203 to add the most recent 3 releases (bringing the total to
33) is unable to pass CI after 8 tries.
>
> Possible solutions fall into two categories: keep the full list and throw
developers and/or more hardware at the struggling tests, or concede that
testing every version is not a scalable approach and find ways to shorten the
list, e.g. randomly select a subset of old versions at runtime, or manually
pare down the list.
>
> I propose to shorten the list [2] by keeping only the latest patch for
each minor (unless the client or server protocol version has changed, so also
keep the patch prior to 1.12.1 and prior to 1.13.2). As long as a patch
release doesn’t change the client or server protocol version, I see low value
in testing upgrades from every patch version to every future version forever.
The months between patch releases already provide plenty of upgrade coverage on
that specific patch, then we can move on to the next…even if there could
somehow be a corner-case where transitive property of upgradability doesn’t
hold, most users probably take the latest-to-latest upgrade path anyway, which
will always be tested.
>
> Let’s keep discussion open until 3PM PST Jan 5. In case of no response,
I will assume lazy consensus and update settings.gradle as proposed [2].
>
>
>
> [1] Current list from
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fsettings.gradle%23L72-L101&data=04%7C01%7Cagingade%40vmware.com%7C8b7e0a65ccc34f37b8a608d9cee8b189%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637768321075908672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Kla9OIPhvSC54LCeIQ%2FhrjOcpn7K39cVBHfAWJlbVh8%3D&reserved=0
:
> 1.0.0-incubating
> 1.1.0
> 1.1.1
> 1.2.0
> 1.3.0
> 1.4.0
> 1.5.0
> 1.6.0
> 1.7.0
> 1.8.0
> 1.9.0
> 1.9.1
> 1.9.2
> 1.10.0
> 1.11.0
> 1.12.0
> 1.12.1
> 1.12.2
> 1.12.3
> 1.12.4
> 1.12.5
> 1.12.6
> 1.12.7*
> 1.13.0
> 1.13.1
> 1.13.2
> 1.13.3
> 1.13.4
> 1.13.5
> 1.13.6*
> 1.14.0
> 1.14.1
> 1.14.2*
> *=released, but not yet added to settings.gradle due to PR#7203 not able
to pass CI due to size of version list
>
> [2] Proposed shortlist:
> 1.1.1
> 1.2.0
> 1.3.0
> 1.4.0
> 1.5.0
> 1.6.0
> 1.7.0
> 1.8.0
> 1.9.2
> 1.10.0
> 1.11.0
> 1.12.0
> 1.12.7
> 1.13.1
> 1.13.6
> 1.14.2
>
