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
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
+1 to what Julian said.
On Wed, Jul 6, 2022 at 9:47 AM Julian Hyde 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
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
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
> 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
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
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
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
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
10 matches
Mail list logo
