Just some housekeeping paper work for export controls per:
http://www.apache.org/licenses/exports/
See https://issues.apache.org/jira/browse/CASSANDRA-14634 and
https://issues.apache.org/jira/browse/LEGAL-358 if you're curios.
On Tue, Sep 25, 2018 at 5:28 PM Nate McCall wrote:
>
> SUBMISSION TYPE
SUBMISSION TYPE: TSU
SUBMITTED BY: Nate McCall
SUBMITTED FOR:The Apache Software Foundation
POINT OF CONTACT: Secretary, The Apache Software Foundation
FAX: +1-919-573-9199
MANUFACTURER(S): The Apache Software Foundation, Oracle, The
OpenSSL Proje
Yeah so lets not derail any further and just put them all to 4.x (as I'm
sure OP originally intended) and we can figure out versioning later.
On Tue, 25 Sep 2018 at 12:07, Mick Semb Wever wrote:
>
>
>
> > I'm totally spitballing here on possible uses of meaningful minors.
>
> Continuing the spli
> I'm totally spitballing here on possible uses of meaningful minors.
Continuing the splitballing…
What about aligning native protocol or sstable format changes with the minor
version?
> Regardless, the OP's statement that new features and improvements should go
> to 4.0.x seems wrong
Ye
This sounds worthy of a bug report! We should at least document any such
inadequacy, and come up with a plan to fix it. It would be great if you could
file a ticket with a detailed example of the problem.
> On 24 Sep 2018, at 14:57, Tom van der Woerdt
> wrote:
>
> Late comment, but I'll wri
I am a big fan of lowering the default number of tokens for many
reasons (availability, repair, etc...). I also agree there are some
usability blockers to "just lowering the number today", but I very
much agree that the current default of 256 random tokens is a huge bug
I hope we fix by 4.0 release
On 9/24/18 12:21 PM, Aleksey Yeshchenko wrote:
> We could continue as 4.0.x, 5.0.x, 6.0.x, 7.0.x, 8.0.x, 9.0.x, with
> minor forever fixed to 0.
>
> But I’m also struggling with how to justify the existence of that
> unused digit. We have never really done semantic versioning, we’ve
> arbitrarily
We could continue as 4.0.x, 5.0.x, 6.0.x, 7.0.x, 8.0.x, 9.0.x, with minor
forever fixed to 0.
But I’m also struggling with how to justify the existence of that unused digit.
We have never really done semantic versioning, we’ve arbitrarily flipped the
major whenever we felt like “it was the righ
I think we’ve confused people plenty so far, that I’m not sure there’s much
confusion to be saved by not making a clean break.
For 3.x (where x > 0 and x < 11) were, after all,
.[.]
For some reason, at 11, we sort of switched back to semver? But seemingly only
to enjoy everyone’s further conf
So as to not confuse people, even if we never put out a 4.1, I think we should
keep it 4.0.x, in line with 2.2.x, 3.0.x, 3.11.x. And yes our .. versioning of the past never followed semver.
-Jeremiah
> On Sep 24, 2018, at 11:45 AM, Benedict Elliott Smith
> wrote:
>
> I’d like to propose we d
I’d like to propose we don’t do Semver. Back when we did this before, there
wasn’t any clear distinction between a major and a minor release. They were
both infrequent, both big, and were treated as majors for EOL'ing support for
older releases. This must surely have been confusing for users,
On 9/24/18 7:09 AM, Joshua McKenzie wrote:
> I propose we move all new features and improvements to 4.0.x to keep the
> surface area of change for the major stable.
It occurs to me that we should probably update the version in trunk to
4.0.0, if we're following semantic versions. I suppose this al
Late comment, but I'll write it anyway.
The main advantage of random allocation over the new allocation strategy is
that it seems to be significantly better when dealing with node *removals*,
when the order of removal is not the inverse of the order of addition. This
can lead to severely unbalance
ok, I guess I should read properly, we should only fix bugs
On Mon, Sep 24, 2018 at 3:42 PM Marcus Eriksson wrote:
> I have used the 4.0 version as a "we need this before releasing 4.0" - do
> you have another way of marking tickets we need fixed before releasing?
>
> On Mon, Sep 24, 2018 at 2:0
I have used the 4.0 version as a "we need this before releasing 4.0" - do
you have another way of marking tickets we need fixed before releasing?
On Mon, Sep 24, 2018 at 2:09 PM Joshua McKenzie
wrote:
> We have quite a few tickets still flagged for 4.0 that aren't in keeping
> with the idea that
We have quite a few tickets still flagged for 4.0 that aren't in keeping
with the idea that the code is frozen:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20(fixversion%20%3D%204.0%20OR%20fixversion%20%3D%204.0.0)%20and%20resolution%20%3D%20unresolved%20and%20type%2
16 matches
Mail list logo
