I like that too, I initially considered proposing that but thought I'd propose delivering v5 and vector support faster but +1 on making these two features a part of 2.0.0 instead.
Štefan Miklošovič <smikloso...@apache.org> escreveu (quinta, 10/10/2024 à(s) 23:37): > I would do 1) and 2) together. I would rename the module in 2.0.0 and > there would be v5 and vector support as well. It would motivate us to get > v5 and vector out while using that opportunity to rename it to 2.0.0. > > On Thu, Oct 10, 2024 at 11:42 AM João Reis <joaor...@apache.org> wrote: > >> Hi, >> >> Following the GoCQL donation we need to change the module name so it >> matches the new repo URL. Currently users have to keep using the old name >> unless they add a rewrite to go.mod. >> >> There was a discussion on what the approach should be on #1776 [1] and >> I've created CASSANDRA-19993 [2] to track this work. Since this is a >> breaking change (it requires users to modify their imports or add a rewrite >> to go.mod) we need to bump the major version when we do this. >> >> With this in mind, there's some topics to discuss: >> >> 1) When do we want to make this module name change happen? We can keep >> doing minor releases under the old module name but it is a bit confusing >> for new users to have to import gocql using a Github repo URL that >> effectively no longer exists. Also the amount of users that will be >> impacted by the module name change will only increase the longer we wait. >> >> 2) Should we take this opportunity to include other breaking change >> related issues with the module name change? Martin mentioned on the gocql >> mailing list [3] that there's a few issues on Github that are tagged with >> "semver-major" [4] and these should be considered for a new major release. >> >> My take on these topics is that we should work on some of those tagged >> issues when we decide to change the module name as long as these breaking >> changes don't require users to significantly rewrite parts of their >> application. We should make this upgrade and module name change to be the >> least intrusive as possible for users. Note that *the >> cassandra-gocql-driver project officially maintains the latest release* >> *only* (single active branch) so doing a major release effectively drops >> support for the previous major immediately which means we have an even >> stronger incentive to make the upgrade as easy as possible. >> >> I'm planning on reviewing protocol v5 and vector support PRs soon and we >> should probably make these 2 contributions available to users as soon as >> possible. To do this we can do a minor release before we start working on >> the next major. I'm also open to the idea that we could postpone the major >> release development and keep doing minor releases for a little longer under >> the old module name. >> >> In summary, my proposal for a short to medium term roadmap is: >> >> 1) Release 1.8.0 with v5 and vector support (and potentially other small >> PRs, I've only looked at these 2 issues yet) >> 2) Release 2.0.0 with the module name change, some (if not all) of the >> "semver-major" tagged issues and other contributions >> >> Let me know your thoughts, >> João Reis >> >> [1] https://github.com/apache/cassandra-gocql-driver/issues/1776 >> [2] https://issues.apache.org/jira/browse/CASSANDRA-19993 >> [3] https://groups.google.com/g/gocql/c/v0FruczBb2w/m/7Hc3_W9QCgAJ >> [4] >> https://github.com/apache/cassandra-gocql-driver/issues?q=is%3Aopen+is%3Aissue+label%3Asemver-major >> >
