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
I totally understand where you are coming from, I've been in the same
situation before, but;
In my experience the only time you want new features in your database is
during development, once the application you built is in production and
stable you really _never_ want to upgrade the db until there
FWIW, here's the ubuntu wiki on their release model:
https://wiki.ubuntu.com/TimeBasedReleases
Short story: they have a feature set for each release, and it must be
tested thoroughly before going out the door. Granted, they are shipping an
entire OS with 1000s of components that all must work well
Agreed. But I think shrinking the release cycle naturally will get features
into usable releases more quickly solving b as well. :)
> On Jun 17, 2014, at 10:28 AM, "Jake Luciani" wrote:
>
> So there are two issues this proposal is trying to address:
>
> 1. Shrink the release cycle.
>
> 2. Bac
So there are two issues this proposal is trying to address:
1. Shrink the release cycle.
2. Backport things to stable releases.
We should discuss these separately since together it's hard to discuss.
1. is less controversial I would think :)
On Tue, Jun 17, 2014 at 1:16 PM, Michael Kjellma
Totally agree — "Also — i’m aware that any additional branches/releases will
add additional work for any developer that works on C*. It would be great if we
could strike a balance that hopefully doesn’t add significant additional
merging/rebasing/work for the team…”
That being said I don’t thin
I agree — but there are lots of people though who lag in adoption while waiting
for more “risky” or “breaking” changes to shake out/stabilize that want to
continue deploying newer fixes. No?
> On Jun 17, 2014, at 9:51 AM, Jake Luciani wrote:
>
> I'm not sure many people have the problem you ar
If that's what we want, merging is going to be much more painful.
Currently we merge:
1.2->2.0->2.1->3.0
If we add an experimental branch for each, we still have to merge the
stable branch into experiemental:
1-2->1.2ex, 2.0->2.0ex, 2.1->2.1ex, 3.0->3.0ex
And then the experimentals into each o
I'm not sure many people have the problem you are describing. This is more
of a C* developer issue than a C* user issue.
Is the below what you are describing we move to?:
1.2 -> 2.0 -> 2.1 -> 3.0 stable
1.2 <- 2.0 <- 2.1 <- 3.0 experimental
Specific changes would be backported based on the "le
It's a bit about features - but it's more an attempt to achieve the goals of
what might happen with a 4 week release cycle (but that itself -- in practice
didn't prove to be valid/reasonable).
If something like an executor service for performance is changed (for example)
it is definitely a mor
Hi Michael,
I didn't get to hear the in person conversation so taking a step back.
The proposal seems to be in response to a common problem. i.e. I'm on C*
version X and I need feature Y which is only available on version Z. Is
this correct?
The options have been: a) upgrade to version Z or b)
No, it generally takes months to reach a minor revision of the current major
release to reach a release stable enough for most to use in production even if
they “live on the edge". Generally there ends up being a very low number of
users who've actively deployed released versions 2.0.0-2.0.5 as
Isn't this how it works now? Aka
2.0 is the "I'm risk averse" stable, and
2.1 is the "I'm living on the edge" stable
__
Sent from iPhone
> On 17 Jun 2014, at 5:16 pm, Michael Kjellman
> wrote:
>
> Hi Dev@ List—
>
> TL;DR:
> I’d love it if we could modify the C* r
Hi Dev@ List—
TL;DR:
I’d love it if we could modify the C* release cycle to include an additional
“experimental” release branch that straddles the current major releases that
includes somewhat “untested” or “risky” commits that normally would only go
into the next major release. Releases based
17 matches
Mail list logo
