Before this PR: Goethe, the library that formats JavaPoet code, upgraded to Java 17 and is a part of the excavator that upgrades dependencies generally speaking. We aren't on Java 17 yet, and there seem to still be a bunch of products/libraries that might be using Java 11 or older.
After this PR:
==COMMIT_MSG==
We remove Goethe from automatic upgrades.
==COMMIT_MSG==
Unfortunately there isn't a nice way to only enable this for 24 years (more realistically, 24 days or some reasonable amount of time)...
Priority: high P2, blocked excavators = sadness
Concerns / possible downsides (what feedback would you like?): How will we remember to disable this at the right time?
Is documentation needed?: No
Compatibility
Does this PR create any API breaks (e.g. at the Java or HTTP layers) - if so, do we have compatibility?: No
Does this PR change the persisted format of any data - if so, do we have forward and backward compatibility?: No
The code in this PR may be part of a blue-green deploy. Can upgrades from previous versions safely coexist? (Consider restarts of blue or green nodes.): Yes
Does this PR rely on statements being true about other products at a deployment - if so, do we have correct product dependencies on these products (or other ways of verifying that these statements are true)?: No
Does this PR need a schema migration? No
Testing and Correctness
What, if any, assumptions are made about the current state of the world? If they change over time, how will we find out?: We're on Java 11. I guess we'll want to do an audit of this when we do the Java 17 migration for AtlasDB.
What was existing testing like? What have you done to improve it?: I don't think it's needed
If this PR contains complex concurrent or asynchronous code, is it correct? The onus is on the PR writer to demonstrate this.: No
If this PR involves acquiring locks or other shared resources, how do we ensure that these are always released?: No
Execution
Only a build-script change.
Scale
Only a build-script change.
Development Process
Where should we start reviewing?: +/-1
If this PR is in excess of 500 lines excluding versions lock-files, why does it not make sense to split it?:
Please tag any other people who should be aware of this PR:
@jeremyk-91
@sverma30
@raiju
General
Before this PR: Goethe, the library that formats JavaPoet code, upgraded to Java 17 and is a part of the excavator that upgrades dependencies generally speaking. We aren't on Java 17 yet, and there seem to still be a bunch of products/libraries that might be using Java 11 or older.
After this PR:
==COMMIT_MSG== We remove Goethe from automatic upgrades. ==COMMIT_MSG== Unfortunately there isn't a nice way to only enable this for 24 years (more realistically, 24 days or some reasonable amount of time)...
Priority: high P2, blocked excavators = sadness
Concerns / possible downsides (what feedback would you like?): How will we remember to disable this at the right time?
Is documentation needed?: No
Compatibility
Does this PR create any API breaks (e.g. at the Java or HTTP layers) - if so, do we have compatibility?: No
Does this PR change the persisted format of any data - if so, do we have forward and backward compatibility?: No
The code in this PR may be part of a blue-green deploy. Can upgrades from previous versions safely coexist? (Consider restarts of blue or green nodes.): Yes
Does this PR rely on statements being true about other products at a deployment - if so, do we have correct product dependencies on these products (or other ways of verifying that these statements are true)?: No
Does this PR need a schema migration? No
Testing and Correctness
What, if any, assumptions are made about the current state of the world? If they change over time, how will we find out?: We're on Java 11. I guess we'll want to do an audit of this when we do the Java 17 migration for AtlasDB.
What was existing testing like? What have you done to improve it?: I don't think it's needed
If this PR contains complex concurrent or asynchronous code, is it correct? The onus is on the PR writer to demonstrate this.: No
If this PR involves acquiring locks or other shared resources, how do we ensure that these are always released?: No
Execution
Only a build-script change.
Scale
Only a build-script change.
Development Process
Where should we start reviewing?: +/-1
If this PR is in excess of 500 lines excluding versions lock-files, why does it not make sense to split it?:
Please tag any other people who should be aware of this PR: @jeremyk-91 @sverma30 @raiju