That's good to hear. I still think it would be good if there was a stated policy about API changes (e.g. "Druid will give notice of not less than two x.0 releases and 1 year before removing a public API") because "We follow semantic versioning" no longer has the same heft under the new version scheme.
On Wed, Jul 6, 2022 at 9:05 PM Gian Merlino <g...@apache.org> wrote: > > I'd say yes, in a way that's similar to today. Today we treat increments of > the version after the 0 as potentially allowing breaking changes. We also > try to avoid them whenever feasible, because we know they're painful for > users. I'm not suggesting we immediately get any more, or less, eager about > making breaking changes as part of dropping the "0.". Over time, though, > I'd like to see us get less eager about making breaking changes. > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org For additional commands, e-mail: dev-h...@druid.apache.org
