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