Next Druid release version scheme

[suneet Saldanha <su...@apache.org>]

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

[rahul gidwani <ch...@apache.org>]

+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 <gi...@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é <xavier@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 <ra...@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 <gi...@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 <ch...@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 <su...@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
>

Re: Next Druid release version scheme

[Julian Hyde <jh...@apache.org>]

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 <gi...@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 <gi...@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é <xavier@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 <ra...@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 <gi...@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 <ch...@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 <su...@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-unsubscribe@druid.apache.org
For additional commands, e-mail: dev-help@druid.apache.org

Re: Next Druid release version scheme

[Gian Merlino <gi...@apache.org>]

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 <gi...@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é <xavier@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 <ra...@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 <gi...@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 <ch...@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 <su...@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
>

Re: Next Druid release version scheme

[Julian Hyde <jh...@apache.org>]

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 <gi...@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é <xa...@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 <ra...@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 <gi...@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 <ch...@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 <su...@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

Re: Next Druid release version scheme

[Gian Merlino <gi...@apache.org>]

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é <xa...@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 <ra...@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 <gi...@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 <ch...@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 <su...@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
> > > > >
> > > >
> > >
> >
>

Re: Next Druid release version scheme

[Xavier Léauté <xa...@confluent.io.INVALID>]

> 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 <ra...@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 <gi...@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 <ch...@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 <su...@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
> > > >
> > >
> >
>

Re: Next Druid release version scheme

[rahul gidwani <ra...@gmail.com>]

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 <gi...@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 <ch...@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 <su...@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
> > >
> >
>

Re: Next Druid release version scheme

[Gian Merlino <gi...@apache.org>]

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 <ch...@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 <su...@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
> >
>

Re: Next Druid release version scheme

[rahul gidwani <ch...@apache.org>]

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 <su...@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
>