Humm — sorry guys — I never got Chris or Jonathan’s responses for some reason.
That being said, sounds like a good compromise Sylvain. Fingers crossed this
turns into a good experiment! Thanks
best,
kjellman
> On Jun 24, 2014, at 10:09 AM, Sylvain Lebresne wrote:
>
> On Tue, Jun 24, 2014 at
On Tue, Jun 24, 2014 at 5:26 PM, Jonathan Ellis wrote:
>
> What if we tried a quicker release cycle, BUT we would guarantee that
> you could do a rolling upgrade until we bump the supermajor version?
> So 2.0 could upgrade to 3.0 without having to go through 2.1. (But to
> go to 3.1 or 4.0 you w
I think you and Marcus are right: the tension is that while some users
want new features faster, others want to keep their cluster as stable
as possible. Right now we kind of have the worst of both worlds -- a
release cycle slow enough that there's a long wait for new features to
stabilize, but fa
On 06/17/2014 01:16 PM, Michael Kjellman wrote:
That being said I don’t think i’m alone by identifying the problem.
FWIW I'm not doing anything wildly unusual and I've been on a fork for
as long as I've been on 1.2 (and various times before). Almost everyone
being on 1.2 with 3 other equally
+1
On Mon, Jun 23, 2014 at 8:19 PM, Jake Luciani wrote:
> +1
>
>
> On Mon, Jun 23, 2014 at 1:59 PM, Sylvain Lebresne
> wrote:
>
> > We've almost there. I propose the following artifacts for release as
> > 2.1.0-rc2.
> >
> > sha1: e2bef02e254a9c6e37a86cab957a1fcba56214fd
> > Git:
> >
> >
> http
