Our messages crossed, so I didn’t see the message where you said “versioning
doesn’t need to be semantic”.
I did not say that Druid should do SemVer; I said that you should have a
policy, and discuss how that policy differs from SemVer.
Julian
> On Dec 21, 2018, at 10:57 AM, Roman Leventov
Julian, I mentioned semantic versioning in the previous message. The
comparison with IntelliJ may seem shocking at first, but actually Druid may
be semantically closer to IntelliJ than to Hadoop or Spark. Druid is a
sever-side *application*, not a library or framework. Like Druid has
extensions
No one has mentioned Semantic Versioning (semver [1]) yet, so I will.
I don't know whether the Druid developers think in terms of semver,
but a lot of your audience will. In semver, the shift from 0. to 1. is
a big event, because the "only remove APIs in major releases" rule
does not apply for
I start to think that Druid versioning doesn't need to be semantic and
doesn't need a distinction between major and minor. A release is just a
release, like IntelliJ's 2018.1, 2018.2, 2018.3. Every release could have
some extensions API broken. If there is an operations breaking change, we
could
If I'm greedily honest, I don't want to maintain that many backport
channels. I'd rather have "If you want XYZ backport for version 14, then
you have to take the latest minor version for 14" and have a policy to
where someone can upgrade from 14.x --> 14.latest with (hopefully) no
config changes.
One nice advantage to moving out of 0.x is that it frees up a digit on the
right side to more cleanly differentiate between "minor release (a random
assortment of bug fixes, small features, etc)" and "patch release
(literally the minimum delta to give you a security fix or high impact bug
fix)".
I'm not too fussy around whether we do a 1.0 or simply drop the 0. and have
it be a 14.0 or 15.0 or 16.0 or wherever we are at the time we do it. I
also like the quarterly cadence of release-from-master we had before we got
blocked on the ASF transition, and would like to pick that back up again
Is there any feeling in the community that the logic behind the releases
needs to change?
If so then I think we should discuss what that release cadence needs to
look like.
If not then dropping the 0. prefix is a marketing / mental item. Kind of
like the 3.x->4.x Linux kernel upgrade. If this is
