What I was trying to suggest is that the *goal* of trunk should always be
releasable, and the alpha releases would be the means of testing that.  If
the goal is to always be releasable, we move towards achieving that goal by
improving modularity, test coverage and test granularity.

Yes, it's very difficult to prove a piece of software is completely free of
bugs and I wouldn't expect NASA to put Cassandra on the space shuttle.
That said, by prioritizing stability in the software development process up
front, the cost of maintaining older branches over time will decrease and
the velocity of the project will increase - which was the original goal of
Tick Tock.


On Fri, Sep 16, 2016 at 9:04 AM Sylvain Lebresne <sylv...@datastax.com>

> On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad <j...@jonhaddad.com>
> wrote:
> >
> > This is a different mentality from having a "features" branch, where it's
> > implied that at times it's acceptable that it not be stable.
> I absolutely never implied that, though I willingly admit my choice of
> branch
> names may be to blame. I 100% agree that no releases should be done
> without a green test board moving forward and if something was implicit
> in my 'feature' branch proposal, it was that.
> Where we might not be in the same page is that I just don't believe it's
> reasonable to expect the project will get any time soon in a state where
> even a green test board release (with new features) meets the "can be
> confidently put into production". I'm not even sure it's reasonable to
> expect from *any* software, and even less so for an open-source
> project based on volunteering. Not saying it wouldn't be amazing, it
> would, I just don't believe it's realistic. In a way, the reason why I
> think
> tick-tock doesn't work is *exactly* because it's based on that unrealistic
> assumption.
> Of course, I suppose that's kind of my opinion. I'm sure some will think
> that the "historical trend" of release instability is simply due to a lack
> of
> effort (obviously Cassandra developers don't give a shit about users, that
> must the simplest explanation).

Reply via email to