Hi Bret, Thanks for bringing up this issue. The Cassandra Analytics library will also need to have its own versioning. We should align on version naming for subprojects and start using it for both the Java Driver and the Analytics library.
I propose the following versioning "java-driver-${version}" for the driver and "analytics-${version}" for Cassandra Analytics. Let me know what your thoughts are. Best, - Francisco On 2024/04/04 05:12:14 Bret McGuire wrote: > Greetings all! For those I haven't met yet I'm Bret and I'm working > mainly on the newly-donated Java driver. As part of that effort we've hit > upon an issue that we felt needed some additional discussion... and so you > now have an email from me. :) > > Our JIRA instance currently has a single field named "Fix Version/s" to > indicate the Cassandra version which will contain a fix for the > corresponding ticket; the field is populated with some (most? all?) > versions of the server. The Java driver has a need for something similar, > but in our case we'd like for the options to correspond to Java driver > releases rather than Cassandra server releases. To be clear there is no > explicit correlation between Java driver releases and any specific server > version or versions. > > How should we model this requirement? We considered a few options: > > * Use the "Fix Version/s" field for both Cassandra and Java driver > versions; basically just add the Java driver versions to what we already > have. There will be some overlap which could cause some confusion; the > most recent Java driver release was 4.18.0 which looks vaguely similar to, > say, 4.1.x. Everybody can figure it out but the overlap might make that > more perplexing than we'd like. > * Add Java driver versions but use some sort of prefix specific to the > driver. So instead of "4.18.0" we might have "java driver 4.18.0". > * Add a new field, perhaps "Java Driver Fix Version/s". This field is only > used for Java driver tickets and is populated with known driver versions > (e.g. "4.18.0") > > Note that whatever choice is made here would presumably apply to *any* > subproject which maintains its own versioning scheme. > > The general consensus of the conversation was that the third option (a > "Java Driver Fix Version/s" field) was the cleanest option but it seemed > worthwhile raising this to the group as a whole. > > Thanks all! > > - Bret - >