Advice requested, declaring this library with a dynamic version or not

[HylkeB]

I am currently deciding how to declare this dependency in my project. I am thinking of declaring this library with a dynamic minor version (version is 2.+). This project states it conforms to semver, so minor and patch updates must always be backward compatible and non breaking.

Normally i define the dependency fully (2.0.1), but for this dependency, because it embeds the log_list.json, I feel like its good to define this dependency with a dynamic version so I also get the latest embedded log_list on every app update, just like chrome does.

How confident are you that you will properly conform to semver, that you not accidentally breaking stuff with a new minor/patch version? Would another approach be better perhaps? Maybe publish a gradle plugin that automatically updates the log_list.json which is embedded by the application/library that consumers of your library have to configure manually, so that there is no risk of accidental bugs in code that get shipped automatically.

Example: our app needs a hotfix, some text is changed, and our CI builds the hotfix and we dont feel like doing a full regression since the code we see is really only some text. This hotfix then breaks our app because of a bug in the latest version of the certificate transparency library which we didnt have in scope.

[mattmook]

Given the setup, patch versions will only ever be updates to the log-list, i.e. all other non-breaking changes will be minor versions.

So if you do decide to use dynamic versioning then for the most safety I would go to the patch version, i.e. use '2.0.+'.

A Gradle plugin or similar mechanism adds a whole extra layer of complexity not just to the users of the library but also to the project itself and I'm not convinced it warrants that. It's worth remembering that the resources copy really is a fallback and in most instances won't actually be used as a later copy should have been downloaded from the network and cached. As part of that it is critical that the project is configured with a disk cache.

[HylkeB]

Thanks for clarifying. I will configure the dependency then as a dynamic patch version, and periodically check if there is a new minor version. It will take a bit of time before we will actually use it in production, the security team is still busy configuring proper CT monitoring.

And of course I have configured a disk cache, but it's nice to have some fallback to be less dependent on the uptime of log list.