Would 24.0 and 25.0 each be regarded as major versions for the purposes of semantic versioning?
If so, under the rules of semantic versioning, we *can* make breaking API changes but that doesn’t mean that we *should*. (For an example of a project that followed the letter of semantic versioning but still undermined the trust of their users by making too many API changes, look no further than Guava.) Julian On Jul 6, 2022, at 1:53 AM, Gian Merlino <g...@apache.org> wrote: My proposal for the next release is that we merely drop the leading "0." and don't change anything else about our dev process. We'd start the next release at 24.0, and then likely do 25.0 shortly after. Same as today, just no leading '0.". Separately, I'd like to craft a better versioning story around extension API, query API, etc. But I don't think we need to connect these two things. The dropping of the leading "0." is mainly about reflecting the reality that the project is way more stable than a random member of the public would expect for a "0." release. The better versioning story is an effort that is independent from that. On Tue, Jun 7, 2022 at 11:50 AM Xavier Léauté <xav...@confluent.io.invalid> wrote: Extension API: do extensions written for version X run as expected with version Y? One thing I'd like to see us do before we declare to 1.0 and provide backwards compatibility for extensions APIs is to remove some of the crufty Hadoop 2.x and Guava 16 dependency constraints we have (or at least isolate them so extensions and core are not constrained by old versions). Removing those will likely be a breaking change for extensions. I'm also fine declaring 1.0, but that might mean we can't deprecate things until 2.0, and then remove those in 3.0 depending on what our backwards compatibility guarantees are. What I'd like us to avoid is to be further entrenched and bogged down in moving away from those dependencies by declaring a stable API. Xavier On Mon, Jun 6, 2022 at 2:45 PM rahul gidwani <rahul.gidw...@gmail.com> wrote: Hi Gian, this is great. For me what is most important is (2) and (4) Does my current extension work with new releases? Can I do a rolling upgrade of druid to the next version? The more things that are versioned the better, but (2) and (4) have been the things that have been most important to me in the past. Anyone in the community have any thoughts on this? Thank you rahul On Fri, May 27, 2022 at 11:22 AM Gian Merlino <g...@apache.org> wrote: Yeah, I'd say the next one after 24.0 would be 25.0. The idea is really just to remove the leading zero and thereby communicate the accurate state of the project: it has been stable and production-ready for a long time. Some people see the leading zero and interpret that as a sign of an immature or non-production-ready system. So I think this change is worth doing and beneficial. I do think we can do better at communicating compatibility, but IMO semantic versioning for the whole system isn't the best way to do it. Semantic versioning is good for libraries, where people need one kind of assurance: that they can update to the latest version of the library without needing to make changes in their program. But Druid is infrastructure software with many varied senses of compatibility, such as: 1) Query API: do user queries written for version X return compatible responses when run against version Y? 2) Extension API: do extensions written for version X run as expected with version Y? 3) Storage format: can servers at version X read segments written by servers at version Y? 4) Intracluster protocol: can a server at version X communicate properly with a server at version Y? 5) Server configuration: do server configurations (runtime properties, jvm configs) written for version X work as expected for version Y? 6) Ecosystem: does version Y drop support for older versions of ZooKeeper, Kafka, Hadoop, etc, which were supported by version X? In practice we do find good reasons to make such changes in one or more of these areas in many of our releases. We try to maximize compatibility between releases, but it is balanced against the effort to improve the system while keeping the code maintainable. So if we considered all of these areas in semantic versioning, we'd be incrementing the major version often anyway. The effect would be similar to having a "meaningless" version number but with more steps. IMO a better approach would be to introduce more kinds of version numbers. In my experience the two most important kinds of compatibility to most users are "Query API" and "Extension API". So if we had a "Query API version" or "Extension API version" then we could semantically version the Query and Extension API versions, separately from the main Druid version. (Each Druid release would have an associated Extension API version, and a list of supported Query API versions that users could choose between on a per-query basis.) Rahul, I wonder what you think about this idea? What kinds of compatibility are most important to you? On Fri, May 27, 2022 at 9:39 AM rahul gidwani <chu...@apache.org> wrote: I would say that semantic versioning for me is very important for determining compatibility between releases. Minor versions should always adhere to being compatible with each other and a major version bump is where you can potentially break it. Right now calling it 24.0 is fine, but what would the next release be called? 25.0? If that is the case, then the number means nothing, every release is a major version and nothing has changed from what it is today except moving a decimal point. Personally I think we should focus on what we are going to do going forward for druid users such that they can be assured that compatibility is met between releases. Right now it is release notes, but if we start using minor versioning like it is intended - that would be much more clear. On Fri, May 27, 2022 at 9:25 AM suneet Saldanha <sun...@apache.org> wrote: Hi Druids, I'd like to propose we bump the version of Druid to 24.0 for the next release. I think this would be beneficial because it better reflects the maturity of the Druid project that is actively used in many production use cases. This was discussed briefly in the Druid 0.23.0 release thread [1]. Other ideas that were proposed * Use a year / month in the release * Make the next release 1.xx I think the year month is interesting, but since we do not have a planned release schedule, it is hard to pick the version that should be in the `master` branch while active dev is happening. Labeling the next release as 1.xx makes it appear as if the current version of Druid isn't very stable since the current version is 0.xx which isn't the case. Happy to hear more opinions on this so we can get to consensus before it is time for the next code freeze + release. [1] https://lists.apache.org/list?dev@druid.apache.org:2022-5:[DISCUSS]%20Druid%200.23%20release
