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%7Cbakera%40vmware.com%7C803bd50439204bf790a208d9c5c24361%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637758261648196421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X3SpCCjuvQo9JO01Di8HM29eKpXPzH9mr2vvpt2fSww%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 >
