I like having the latest patch release always brought in for testing and CI for the JDK versions explicitly supported. So for this release, 11/17. On Jun 22, 2023, at 5:42 PM, Jeremiah Jordan <jeremiah.jor...@gmail.com> wrote:
Yes. -1 on forcing the patch release version, and possibly minor version, for anything that is not absolutely necessary to do so. Especially for things like Java or Python version, I would hope we just install the latest Java 8, Java 11, or Java 17 JDK for the platform the image is built from and run under them. Otherwise we don’t find out until it’s too late when some JDK update breaks things. I know I always tell users to run the latest JDK patch release, so we should do the same.
If we want to pin the major version of something, then I have no problem there.
-Jeremiah
Wouldn’t we recommend people to use the test images the project CI use? Thus using in testing the versions we use? I would assume the repeatable CI will still expect test images the way we have now? (I hope I did not misunderstand the question)
I also share similar worries with Brandon
On Thu, Jun 22, 2023 at 4:23 PM Josh McKenzie <jmcken...@apache.org> wrote:
>
> 2. Anyone concerned about us being specific about versions in requirements.txt in the dtest repo?
My concern with this is atrophy; we'll set the version once and when
finally forced to update, find that a lot of other things must also be
updated in order to do so. I think our current approach of only
setting them on things we require at a certain version like thrift has
been successful thus far, and I don't think having different versions
would be very common, but also not really affect repeatability if
encountered. You can see what versions are used from the logs though
and could adjust them to be the same if necessary.
|
