+1 to what Julian said.
On Wed, Jul 6, 2022 at 9:47 AM Julian Hyde <jh...@apache.org> wrote: > 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 >
