Hello,
I would recommend aligning with database versioning scheme (so 9.5.x) ; it would have been clearer from the start if the version numbers had never been close, but any change now seems arbitrary and confusing (even if I prefer semantic versioning in general).
Regarding semantic versioning, the "major" component here is the JDBC API, so you can probably disregard A.B -- as in 9.5 -- as a marker saying "we've tried it with that version, and it works". Then, even if it's not fully compliant with proper semantic versioning, use the C (of A.B.C) as a marker for feature changes, and the trailing qualifier for patches.
For example:
9.4.C.D => any version tested with 9.4.x (backend)
9.5.C.D => tested with 9.5
9.5.1.000 => first build approved for 9.5 backend
9.5.2.000 => like 9.5.1.0 but with feature changes (new packaging, new properties, new capabilities, etc)
9.5.1.001 => like 9.5.1.0 but with bugfixes (with no new features)
The prefixed zeros for "D" enable alphanumerical sorting (with OSGi Version objects, for example), and I personally find it more usable (readable) than 20160314 for example (even if that sorts too ; it doesn't look like a nightly snapshot tag). And I imagine there'll still be -jre6, -jre7, -jre8 variants to distinguish API target versions.
Hope that helps,
Christopher
On 14 March 2016 at 15:14, Dave Cramer
<pg@fastcrypt.com> wrote:
My thoughts:
releasing 9.5 is the path of least resistance.
Ideally we announce that we are going to release version 42.x.y. however nobody will pay attention until their build breaks.
Then we will get a flood of messages implying that we broke their build.
My gut says to go with 42.x.y, my head says it will be easier to take the easy way out and release 9.5.x
