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?
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
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
wrote:
> We should definitely move away from the `0.xx`
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
Build Update for apache/druid
-
Build: #36801
Status: Broken
Duration: 6 mins and 25 secs
Commit: d0c9c37 (master)
Author: Clint Wylie
Message: make query context changes backwards compatible (#12564)
Adds a default implementation of getQueryContext, which
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
