Re: Next Druid release version scheme
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 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 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 > > >
Re: Next Druid release version scheme
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 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 >
Re: [DISCUSS] Druid 0.23 release
Thank you, Suneet. On Fri, May 27, 2022 at 9:46 PM Suneet Saldanha wrote: > Agreed. Naming is hard, and I wouldn't want to slow down this release > trying to get > consensus on the correct versioning scheme. They all seem to have merits. > I will start > another thread to discuss this so we will have a decision by the time the > next release > rolls around. > > On 2022/05/27 02:57:39 rahul gidwani wrote: > > What about a 1.0 release? I think there is no backwards compatibility > promised until Druid gets to 1.0+. I think it would be really helpful to > customers to start making upgrades rollable and guaranteeing compatibility > between minor versions. Any plans for this to happen in the near future? > > > > > On May 26, 2022, at 7:16 PM, Gian Merlino wrote: > > > > > > I'm supportive of changing the versioning to something without the > leading > > > zero in the next release where this is practical. If it's the one after > > > 0.23.0, then I would go with 24.0. IMO, going with 1.0 would send a > message > > > that this is the first mature release. But that isn't the case: we have > > > been doing mature releases for a long time now. Going with 24.0 is > clearer > > > in that regard. > > > > > > Happy to repeat this opinion on a new thread too :) > > > > > >> On Thu, May 26, 2022 at 6:49 PM Frank Chen > wrote: > > >> > > >> For 0.23, I don't think we need to make changes because I think it > may take > > >> us some time to reach an agreement on the naming. > > >> > > >> We can start a new thread to discuss the versioning schema. > > >> > > >> > > >> On Thu, May 26, 2022 at 8:19 PM Abhishek Agarwal < > > >> abhishek.agar...@imply.io> > > >> wrote: > > >> > > >>> We should definitely move away from the `0.xx` versioning scheme we > have > > >>> been using. However, the next version that we pick up is debatable. > > >> `23.x` > > >>> seems an odd jump from `0.23`. Can we increment the version to `1.x` > > >> maybe? > > >>> I also like the idea of using Yeah and Month that Frank has > suggested. > > >>> > > >>> I don't think that 0.23 is the right release to make this change > though. > > >>> 0.23 has already been delayed because of CVE investigations and bug > > >> fixes. > > >>> I would like to get this release out of the door as soon as possible. > > >>> > > On Thu, May 26, 2022 at 2:40 PM Frank Chen > wrote: > > >>> > > I agree. > > > > This is also a question that I want to ask why the version is still > > >> 0.xx > > which gives many people a hint that Druid is still under mature. > > > > There are many versioning schemas. One popular way is combining the > > >>> release > > year and month in the version. > > For example, if we're going to release a version in May this year, > the > > >>> main > > version can be 22.5. > > > > > > Versioning is one thing, LTS strategy should also be clear. > > Since we're going to release several versions a year, we should > plan in > > advance which one should be scheduled as a LTS version and maintain > it > > >>> for > > a period of time if there are some vital bugs and security issues. > > > > > > > > > > On Thu, May 26, 2022 at 1:21 PM Suneet Saldanha > > >>> wrote: > > > > > Hi all, > > > > > > I've been thinking that we should consider re-branding this release > > >> as > > > the Druid 23.0 instead of 0.23 release. I think this is appropriate > > because > > > typically a `0.XX` software version implies that the software is in > > >>> it's > > > infancy. > > > > > > Druid is quite mature, and we've been putting good guardrails in > > >> place > > >>> to > > > detect and prevent breaking API changes in each release. Druid has > > >> also > > > been running in production clusters for many different use cases > for > > quite > > > some > > > time now. I think version 23.0 is more in line with the maturity of > > >> the > > > project. > > > > > > Is there a reason not to change the version for the next release? > Any > > > other thoughts? > > > > > > On 2022/04/11 10:21:11 Abhishek Agarwal wrote: > > >> Thank you for creating that PR, Frank. In the last release, we > > >>> excluded > > >> helm charts since we were not sure about IP clearance. From > > >> https://incubator.apache.org/ip-clearance/, we should decide on > IP > > >> clearance whether we include helm charts in artifacts or not. Any > > > thoughts? > > >> > > >> On Wed, Mar 30, 2022 at 4:44 PM Frank Chen > > wrote: > > >> > > >>> Hi Abhishek, > > >>> > > >>> Thank you for starting the release work. > > >>> > > >>> This PR should be merged to address a problem caused by a > > >> previous > > PR: > > >>> https://github.com/apache/druid/pull/12067 > > >>> I've added it to the 0.23 milestone. > > >>> > > >>> > > >>> Thank you. > >
Next Druid release version scheme
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
Re: [DISCUSS] Druid 0.23 release
Agreed. Naming is hard, and I wouldn't want to slow down this release trying to get consensus on the correct versioning scheme. They all seem to have merits. I will start another thread to discuss this so we will have a decision by the time the next release rolls around. On 2022/05/27 02:57:39 rahul gidwani wrote: > What about a 1.0 release? I think there is no backwards compatibility > promised until Druid gets to 1.0+. I think it would be really helpful to > customers to start making upgrades rollable and guaranteeing compatibility > between minor versions. Any plans for this to happen in the near future? > > > On May 26, 2022, at 7:16 PM, Gian Merlino wrote: > > > > I'm supportive of changing the versioning to something without the leading > > zero in the next release where this is practical. If it's the one after > > 0.23.0, then I would go with 24.0. IMO, going with 1.0 would send a message > > that this is the first mature release. But that isn't the case: we have > > been doing mature releases for a long time now. Going with 24.0 is clearer > > in that regard. > > > > Happy to repeat this opinion on a new thread too :) > > > >> On Thu, May 26, 2022 at 6:49 PM Frank Chen wrote: > >> > >> For 0.23, I don't think we need to make changes because I think it may take > >> us some time to reach an agreement on the naming. > >> > >> We can start a new thread to discuss the versioning schema. > >> > >> > >> On Thu, May 26, 2022 at 8:19 PM Abhishek Agarwal < > >> abhishek.agar...@imply.io> > >> wrote: > >> > >>> We should definitely move away from the `0.xx` versioning scheme we have > >>> been using. However, the next version that we pick up is debatable. > >> `23.x` > >>> seems an odd jump from `0.23`. Can we increment the version to `1.x` > >> maybe? > >>> I also like the idea of using Yeah and Month that Frank has suggested. > >>> > >>> I don't think that 0.23 is the right release to make this change though. > >>> 0.23 has already been delayed because of CVE investigations and bug > >> fixes. > >>> I would like to get this release out of the door as soon as possible. > >>> > On Thu, May 26, 2022 at 2:40 PM Frank Chen wrote: > >>> > I agree. > > This is also a question that I want to ask why the version is still > >> 0.xx > which gives many people a hint that Druid is still under mature. > > There are many versioning schemas. One popular way is combining the > >>> release > year and month in the version. > For example, if we're going to release a version in May this year, the > >>> main > version can be 22.5. > > > Versioning is one thing, LTS strategy should also be clear. > Since we're going to release several versions a year, we should plan in > advance which one should be scheduled as a LTS version and maintain it > >>> for > a period of time if there are some vital bugs and security issues. > > > > > On Thu, May 26, 2022 at 1:21 PM Suneet Saldanha > >>> wrote: > > > Hi all, > > > > I've been thinking that we should consider re-branding this release > >> as > > the Druid 23.0 instead of 0.23 release. I think this is appropriate > because > > typically a `0.XX` software version implies that the software is in > >>> it's > > infancy. > > > > Druid is quite mature, and we've been putting good guardrails in > >> place > >>> to > > detect and prevent breaking API changes in each release. Druid has > >> also > > been running in production clusters for many different use cases for > quite > > some > > time now. I think version 23.0 is more in line with the maturity of > >> the > > project. > > > > Is there a reason not to change the version for the next release? Any > > other thoughts? > > > > On 2022/04/11 10:21:11 Abhishek Agarwal wrote: > >> Thank you for creating that PR, Frank. In the last release, we > >>> excluded > >> helm charts since we were not sure about IP clearance. From > >> https://incubator.apache.org/ip-clearance/, we should decide on IP > >> clearance whether we include helm charts in artifacts or not. Any > > thoughts? > >> > >> On Wed, Mar 30, 2022 at 4:44 PM Frank Chen > wrote: > >> > >>> Hi Abhishek, > >>> > >>> Thank you for starting the release work. > >>> > >>> This PR should be merged to address a problem caused by a > >> previous > PR: > >>> https://github.com/apache/druid/pull/12067 > >>> I've added it to the 0.23 milestone. > >>> > >>> > >>> Thank you. > >>> > >>> > >>> On Wed, Mar 30, 2022 at 2:15 PM Abhishek Agarwal < > >>> abhishek.agar...@imply.io> > >>> wrote: > >>> > Hello everyone, > It's time to kick-off the process for druid 0.23 release. I > >> will > need > >>> help > from the community in
