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 > > >
