I agree that not releasing semi-regularly is not good for the project. I think
our habit of releasing half working software is much worse though. Our
testing/stability story is not iron clad. I really think the bar for releasing
4.0 should be that the people in this thread are running the code in
production, recommending their customers run it in production, or offering and
supporting it as part of their cloud service.
In that context, the argument for waiting for some features is less about
trying to do all the things and more about making 4.0 something worth the time
and expense of validating for production.
On 4/11/18, 1:06 AM, "Sylvain Lebresne" <lebre...@gmail.com> wrote:
On Wed, Apr 11, 2018 at 12:35 AM Jeff Jirsa <jji...@gmail.com> wrote:
> Seriously, what's the rush to branch? Do we all love merging so much we
> want to do a few more times just for the sake of merging? If nothing
> diverges, there's nothing gained from the branch, and if it did diverge,
we
> add work for no real gain.
>
Again, to me, the "rush" is that 1) there is tons of changes sitting in
trunk
that some user (_not all_, granted)[1], especially new ones, would likely
benefits, and sooner for those is better than later, 2) we want to favor
release stability and we *know* from years of experience (and frankly,
common
sense) that the bigger the release is, the harder it is to test it/ensuring
overall stability[2] and 3) not having major releases for years[3] is
impacting at least the perceived dynamism/liveness of the project to
external
actors (prospective new user come in mind here, but not only) and that's
simply bad for the project.
And having listed arguments for a soon freeze/not accumulating much more
before release, I'd like to reverse the question to you: what are the big
downsides of not doing that? Are we really that hung up on our own
developers
comfort that the annoyance of a bit more merging trumps the arguments above?
Anyway, the reasons above make me thing that it's better _for the project_
to freeze 4.0 soon, which doesn't exclude a "short" cycle for the following
major (where my definition of short here is something like 6-8 months), and
I'm happy to decide to make 4.0 a non-mandatory upgrade to whatever
comes next so that folks that prefer upgrading rarely can simply skip it and
go to the next one. Likely nobody will die if we wait more though, and it's
clear it will make a few people here more happy if we do, but I believe the
project as a whole will be a bit worst off, that's all.
--
Sylvain
[1]: I'll note that I don't deny upgrading is huge deal for some users, but
let's not skew arguments too much based on any one user interest. For many
users, upgrading even every year to get improvements is still considered as
a
good deal, and that's not counting new users for which it's super
frustrating
to miss out on improvements because we release major only every 2+ years.
[2]: I'll be clear: I will simply not buy anyone argument that "we'll do
so much better testing this time" on face value. Not anymore. If you want to
use that argument to sell having bigger releases, then prove it first. Let's
do reasonably sized 4.0 and 4.1/5.0 and prove that our testing/stability
story
is iron clad now, and then for 4.2/6.0 I'll be willing to agree that making
bigger release may not impact stability too much.
[3]: Conservative estimate, if we do care about stable releases as we all
seem
to, even if we were to freeze June 1, we will almost surely not release
before
October/November, which will be ~1.3 year since the last major release
(again,
that's the conservative estimate). If we push a few months to get some big
complex feature in, not only this push the freeze of those few months, but
will also require more testing, so we're looking at 2+ years, with a
possibly
large '+'.
>
> Beyond that, I still don't like June 1. Validating releases is hard. It
> sounds easy to drop a 4.1 and ask people to validate again, but it's a
hell
> of a lot harder than it sounds. I'm not saying I'm a hard -1, but I really
> think it's too soon. 50'ish days is too short to draw a line in the sand,
> especially as people balance work obligations with Cassandra feature
> development.
>
>
>
>
> On Tue, Apr 10, 2018 at 3:18 PM, Nate McCall <zznat...@gmail.com> wrote:
>
> > A lot of good points and everyone's input is really appreciated.
> >
> > So it sounds like we are building consensus towards June 1 for 4.0
> > branch point/feature freeze and the goal is stability. (No one has
> > come with a hard NO anyway).
> >
> > I want to reiterate Sylvain's point that we can do whatever we want in
> > terms of dropping a new feature 4.1/5.0 (or whatev.) whenever we want.
> >
> > In thinking about this, what is stopping us from branching 4.0 a lot
> > sooner? Like now-ish? This will let folks start hacking on trunk with
> > new stuff, and things we've gotten close on can still go in 4.0
> > (Virtual tables). I guess I'm asking here if we want to disambiguate
> > "feature freeze" from "branch point?" I feel like this makes sense.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
