figure out release

[bavardage]

• what version to jump to?
• message backcompat break (w.r.t. java 7 support)

[a-k-g]

Can we release some time soon? I want to use the encrypted-config-value library and it seems there's been some refactoring since the last release.

[nmiyake]

• The candidates would be 1.1.0 or 2.0.0, right? I'm fine with either one.
• Release notes should also mention changes caused by Use a standard IV length for AES keys #56 and Refactor and fix algorithms while maintaining back-compat #67, which changed both algorithms used for encryption and the serialization format. It's very important to note that the values written by the next version cannot be read by previous versions. Perhaps this would point to a 2.0 version being more appropriate to signal this large-scale change (although this code does provide backcompat for reading all previously generated values so it doesn't break backcompat in the strictest sense).

[gauravtiwari89]

@bavardage Any chance we could release soon? Some of the fixes that @nmiyake put in for encryption in #67 are fairly blocking for us.

[bavardage]

yeah, we can cut 1.1.0

[nmiyake]

Should the version be 2.0? Otherwise, we will be in a case where values written by 1.1.0 can't be read by 1.0.0, which seems counter-intuitive (although not sure if it's actually wrong/violates semver)

[bavardage]

don't have a strong opinion/don't believe we ever explicitly declared what our semver contract was

[bavardage]

so sure, can do 2.0.0

[j-baker]

retro: did we actually derive any value from the rewrite? At the moment it seems kinda negative value in general - basically

• we wrote all the code which took presumably a bunch of time and effort
• we then didn't release it for exactly 365 days
• it caused many breaks internally as a direct consequence, and has blocked numerous upgrades. Personally I've spent at least 1 working day fixing this in a single place.
• we actually don't generate the version 2 format internally, which means that we just fall back to the old thing, which causes an exception to be thrown and immediately caught
• we can't generate the version 2 format internally without there being large cross-team coordination
• this just means that every time we deserialize config, we now have to fill in #secrets stack traces
• there's also going to have to be some dev work to this from people unfamiliar with the codebase in order to deal with 2.x breaks, because 1.x let you use whatever key type you wanted, and 2.x only lets you use AES, whereas we have some real usages of EC internally which are in super-legacy code

but maybe it provided us with some benefit somewhere?

[bavardage]

The reasoning behind releasing now was the need to run on a non-standard JVM (running on an IBM AIX machine). This also brings us to a format which is easier to support in non-java codebases (go, rust, etc).

All breaks I've seen have been people using the library in a non-intended way, namely using it for things other than deserializing sensitive items in a config file.

Agree it's odd we're not generating the version 2 format in deployment infrastructure.