This is a proposal to strike the code change action from the bylaws. This
is being requested because there is substantial ambiguity about the
standards being declared / whether this should be part of our bylaws and,
until these are clarified, should be removed.
Specifically, it is the following li
This is a proposal to change the Bylaw Change action in the bylaws from
Majority Approval to Consensus Approval. This is being requested because
Bylaw changes are a major change to the project and all discussion should
be able to be had without a borderline majority being able to force things
thro
i
> >
> >
> > On Fri, Apr 4, 2014 at 11:18 AM, Josh Elser
> wrote:
> > > +1
> > >
> > > Minor correction, the bylaws currently state "version 0" so it should
> be
> > > replaced with "version 1".
> > >
> >
In the bylaw discussion, we had discussed the potential for someone to
reject a commit as a method to reject a release. Is this something that we
want to guard against with every release (if possible, we may need to
provide this ability in the bylaws) or should there be language in our
definitions
opher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > > >
> > > > On Fri, Apr 4, 2014 at 11:33 AM, David Medinets
> > > > wrote:
> > > > > +1
> > > > >
> > > > >
> > &
em more ammunition to work with.
>
> It is generally best to provide a reasonably loose set of community
> standards and then rely on the communities shared interest.
>
> -Sean
>
>
> On Fri, Apr 4, 2014 at 11:19 AM, John Vines wrote:
>
>> In the bylaw discussion, w
+1 for the initial changes Billie proposed.
On Fri, Apr 4, 2014 at 12:53 PM, Sean Busbey wrote:
> Yes, precisely.
>
>
> On Fri, Apr 4, 2014 at 11:47 AM, John Vines wrote:
>
> > That makes sense, Sean. So are you saying that you think it's best to
> > include
Based on the actions table, consensus
On Fri, Apr 4, 2014 at 1:06 PM, Keith Turner wrote:
> On Fri, Apr 4, 2014 at 12:12 PM, Billie Rinaldi >wrote:
>
> > This is a proposal to adequately describe our Commit-Then-Review process
> in
> > the bylaws. I have made an initial suggestion below. If
So, I pseudo got an explanation for the second point in the CtR discussion,
so I'm going to withdraw that comment. However, I would still appreciate an
explanation for initial paragraph.
On Fri, Apr 4, 2014 at 12:32 PM, John Vines wrote:
> The majority of the reasoning I read in th
This is something that crossed my mind recently. Hadoop 2 is solidly moving
forward and, as someone who does not actively follow the hadoop community,
hadoop 1 is slowing down. Adoption for hadoop2 is on the rise and with that
I'm starting to wonder whether it's worth the code complexity to support
doop 1 support already.
> >
> >
> > On Fri, Apr 4, 2014 at 10:54 AM, John Vines wrote:
> >
> > > This is something that crossed my mind recently. Hadoop 2 is solidly
> > moving
> > > forward and, as someone who does not actively follow the hadoop
>
wrote:
>
>
>
> On Fri, Apr 4, 2014 at 12:19 PM, John Vines wrote:
>
>> So, I pseudo got an explanation for the second point in the CtR
>> discussion,
>> so I'm going to withdraw that comment. However, I would still appreciate
>> an
>> explanation for init
n if we're providing the clarity on the vote type at the
start of the vote, which they can reference against our bylaws when they
see it's a different type then what they expected.
On Fri, Apr 4, 2014 at 2:24 PM, Sean Busbey wrote:
>
> On Fri, Apr 4, 2014 at 1:18 PM, John Vines
I'm okay with Josh's suggestion of both.
Sent from my phone, please pardon the typos and brevity.
On Apr 5, 2014 10:23 PM, "Christopher" wrote:
> Acknowledged.
>
> I do want to hear from Mike Drob and John Vines first before I take
> any further action on this, t
+1
Sent from my phone, please pardon the typos and brevity.
On Apr 7, 2014 10:11 AM, "Billie Rinaldi" wrote:
> Please vote on applying the following changes to the Accumulo bylaws (
> http://accumulo.apache.org/bylaws.html). If the "Code Change" action has
> been removed, it will be reintroduce
Given our support of backwards compatibility, does anyone have a preference
for how traces are stored?
I ask because I have noticed some places where our internal trace hooks are
named with collisions so that you get multiple events with the same
identifier which are actually different events. I w
client:update
1+1609 tserver@localhost update
1+1609 tserver@localhost wal
On Mon, Apr 7, 2014 at 11:05 AM, Mike Drob wrote:
> Can you give an example of where this happens?
>
>
> On Mon, Apr 7, 2014 at 10:54 AM, John Vines wrote:
>
> >
tart the vote, but I had thought that
> somebody else (maybe John Vines?) had volunteered to be the release
> manager for 1.6.0, though I can't find the thread at the moment (if
> there was one).
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
-1 due to ACCUMULO-2700
On Thu, Apr 17, 2014 at 11:25 PM, Josh Elser wrote:
> Just ingested 500M entries with CI and verified them successfully too.
>
>
> On 4/17/14, 6:59 PM, Josh Elser wrote:
>
>> +1
>>
>> * Built and tested (unit and integration) src tarball against Apache
>> Hadoop 2.2.0, 2
Just because they're old doesn't make them invalid. They're just at a lower
priority. Closing them for the sake of closing them seems like a bad idea.
But if they're actually invalid now, that's an entirely different notion.
Sent from my phone, please pardon the typos and brevity.
On Apr 19, 2014
en helps us track/manage outstanding work. (The obvious
> question, then, is "does it help in some way?"). They can always be
> re-opened if we decide it's worth doing.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Sat, Apr 19, 2014 at
onvenient point of
> > reference.
> >
> > Maybe this would be a good use of our ASF wiki space?
> >
> >
> > On Sat, Apr 19, 2014 at 3:50 PM, Corey Nolet wrote:
> >
> > > I agree. Are those tickets really getting in the way? Maybe they could
> be
-1
On Tue, Apr 22, 2014 at 11:49 AM, Sean Busbey wrote:
> -1 due to ACCUMULO-2713
>
>
> On Mon, Apr 21, 2014 at 5:02 PM, Christopher wrote:
>
> > Accumulo Developers,
> >
> > Please consider the following candidate for Accumulo 1.6.0.
> >
> > Git Commit: 901c35857ce982f2e4a6f609590a04a7b5a1a81
+1
On Wed, Apr 23, 2014 at 10:53 AM, Josh Elser wrote:
> On 4/23/14, 10:47 AM, Sean Busbey wrote:
>
>> Okay, I think all of these incompatibilities are things that should not
>> have been in the public API in the first place.
>>
>> * client.admin.SecurityOperationsImpl
>> * client.admin.TableOp
Please change the subject if you're going to change this into a
conversation about when to start votes. This subject is for votes for an RC
candidate.
On Mon, Apr 28, 2014 at 11:30 AM, William Slacum <
wilhelm.von.cl...@accumulo.net> wrote:
> I was concerned about the lack of activity. I don't h
+1
On Fri, Apr 25, 2014 at 8:35 PM, Christopher wrote:
> Accumulo Developers,
>
> Please consider the following candidate for Accumulo 1.6.0.
>
> Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
> Branch: 1.6.0-RC4
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgap
+1 b
+0 c
On Mon, Apr 28, 2014 at 9:48 PM, Bill Havanki wrote:
> b, and prefer c over d but not overly so
>
>
> On Mon, Apr 28, 2014 at 7:45 PM, Sean Busbey wrote:
>
> > B and C (though I would like subtasks to be listed last)
> >
> >
> >
> > On Mon, Apr 28, 2014 at 6:41 PM, Josh Elser
> wrote
+1 verified signatures and checksums, ran tests against hadoop 1 and 2.
On Tue, Apr 29, 2014 at 5:33 PM, Christopher wrote:
> Accumulo Developers,
>
> Please consider the following candidate for Accumulo 1.6.0.
>
> Git Commit: 06162580e885f11863d1a6d22f952bce35b78b68
> Branch: 1.6.0-RC5
>
> Sta
This vote passed +4 to -3 19 days ago, but was missed. I am updating the
website now to make these changes.
On Fri, Apr 4, 2014 at 2:41 PM, John Vines wrote:
> That leaves me conflicted. I have a substantial dislike for doing things a
> way solely because that's how they have been
+0
I want to EOL 1.4.x but I am having difficulties following this discussion.
If someone could provide a tldr; I will probably change my vote.
On Tue, May 6, 2014 at 12:31 PM, Ryan Leary wrote:
> +1
>
> Thanks for encouraging votes from non-committers. I think having three
> major versions si
Why eliminate the 1.6.1-SNAPSHOT branch for 1.7.0-SNAPSHOT? Why not just
branch the master and insert a 1.7.0-SNAPSHOT into our workflow after
1.6.1-SNAPSHOT and before master?
On Mon, May 12, 2014 at 11:10 AM, Bill Havanki wrote:
> I like this plan overall. I am definitely in favor of more freq
/DfsLogger.java
<https://reviews.apache.org/r/21557/#comment77307>
I think that before this loop the closeLock and/or closed should be checked
and if it is closed, then LogClosedExceptions should be placed on all of the
LogWorks, not the Exception received.
- John Vines
On May 16, 2014
Yes, restore the old behavior
On Wed, May 14, 2014 at 4:38 PM, Sean Busbey wrote:
> We don't have a formal onboarding process for drawing in new contributors,
> but a recent ASF Infra change impacts what I've observed historically.
>
> Here's what I've seen historically, more or less:
>
> 1) So
My comfort with this is based solely on the amount of effort and complexity
involved. I have no direct qualms with providing that path, on the
assumption we don't spend an exorbitant amount of hours developing it and
end up with a ridiculous amount of code brought up to support this which we
have t
Unfortunately to run the shell, it does seem like accumulo-env.sh needs to
be readable, even in the case where you have those variables set (and are
using the shell's -z flag). There seems to be a hack by setting
ACCUMULO_TEST env var, but that seems really hacky and rediculous.
On Wed, Jun 11, 2
nnector("root", "secret").tableOperations().create("macCreated");
System.out.println("Stopping");
mac.stop();
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running t
views.apache.org/r/23397/#review47585
---
On July 10, 2014, 5:24 p.m., John Vines wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://review
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
;Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
ntln("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
> On July 10, 2014, 5:50 p.m., Sean Busbey wrote:
> > minicluster/src/main/java/org/apache/accumulo/minicluster/MiniAccumuloConfig.java,
> > line 259
> > <https://reviews.apache.org/r/23397/diff/1/?file=627812#file627812line259>
> >
> > nit: whitesapce
> On July 10, 2014, 8:42 p.m., Christopher Tubbs wrote:
> > -1
> > There's absolutely no reason to create a profile and options to skip the
> > execution of the plugin since there is a built-in mechanism for controlling
> > the rat check's impact on the build (eg. by setting rat.ignoreErrors).
In using MAC on 1.6.1-SNAPSHOT, I noticed that the configimpl has a
setProperty that is not exposed in the general MiniAccumuloConfig. Is this
intentional or an oversight?
mb in.
- John
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23397/#review47622
---
On July 10, 2014, 6:43 p.m., J
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
That is my issue with Keith. Requiring a double dot upgrade to do a single
dot upgrade is a pretty big break in our operating procedure up until this
point.
How do we ensure people don't go to 1.7.0 straight from 1.6.1 and earlier
versions?
On Wed, Jul 23, 2014 at 10:03 AM, Keith Turner wrote:
Go for it!
Sent from my phone, please pardon the typos and brevity.
On Sep 3, 2014 4:13 PM, "Jenna Huston" wrote:
> John Vines, would it be ok if I worked on and submitted a patch to
> Accumulo ticket 2841?
>
> Thanks!
> Jenna
>
Moving this to it's own thread...
On Mon, Oct 6, 2014 at 5:54 PM, Mike Drob wrote:
> Related: Do we have a release timeline for 1.7?
>
> On Mon, Oct 6, 2014 at 4:51 PM, Christopher wrote:
>
> > On Mon, Oct 6, 2014 at 5:20 PM, Sean Busbey wrote:
> >
> > > On Mon, Oct 6, 2014 at 4:12 PM, Mike Dr
d mini instance.
I'm gonna be blunt - this is really really hard and I think it can be punted to
a ticket for future work
- John
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apa
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23397/#review47661
-------
On July 10, 2014, 10:48 p.m., John Vines wrote:
>
> -
-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
File Attachments (updated)
0001-ACCUMULO-2984-support-running-MAC-against-a-real-acc.patch
https://reviews.apache.org/media/uploaded/files/2014/10/15/1ee9c409-65de-4a44-a86e-e905b4593a8f__0001-ACCUMULO-2984-support-running-MAC-against-a-real-acc.patch
Thanks,
John Vines
UMULO-2984-support-running-MAC-against-a-real-acc.patch
https://reviews.apache.org/media/uploaded/files/2014/10/15/d38c6150-4320-41e1-8495-b42d050ddc93__0001-ACCUMULO-2984-support-running-MAC-against-a-real-acc.patch
Thanks,
John Vines
port-running-MAC-against-a-real-acc.patch
https://reviews.apache.org/media/uploaded/files/2014/10/15/d38c6150-4320-41e1-8495-b42d050ddc93__0001-ACCUMULO-2984-support-running-MAC-against-a-real-acc.patch
Thanks,
John Vines
tem.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
egressions would be really nice. Might be able to
> > start a mini instance, stop it, use internal exec methods to start a
> > zookeeper, and then point another mac to the old mini instance.
>
> John Vines wrote:
> I'm gonna be blunt - this is really really
ntln("Stopping");
mac.stop();
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
egressions would be really nice. Might be able to
> > start a mini instance, stop it, use internal exec methods to start a
> > zookeeper, and then point another mac to the old mini instance.
>
> John Vines wrote:
> I'm gonna be blunt - this is really really
egressions would be really nice. Might be able to
> > start a mini instance, stop it, use internal exec methods to start a
> > zookeeper, and then point another mac to the old mini instance.
>
> John Vines wrote:
> I'm gonna be blunt - this is really really
ntln("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
;Stopping");
mac.stop();
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
ccumulo
doesn't work with a new ZK instance, why would you expect the MAC equivalent to?
- John
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23397/#review57431
---
On Oct. 20, 2014, 8:0
2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
nstance 2
> > uses ZK2)
> >
> > I think the code gets stuck trying to connect to ZK1, when trying to
> > connection to Accumulo instance 2
>
> John Vines wrote:
> So you're expecting this to work with a new zookeeper? Standard Accumulo
> doesn&#x
elated to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
").tableOperations().create("macCreated");
System.out.println("Stopping");
mac.stop();
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
Makes me think the Range(Text row) constructor should be row, true, row,
false
On Fri, Oct 24, 2014 at 10:53 AM, Andrew Wells
wrote:
> It may be need to change either the implementation of Key::new(Text row),
> or change the way Range::exact(Text row) matches
>
> Trace on Key::new(Text row)
> li
g
BulkIT still functions as intended for validation of no feature loss in
refactoring exiting code for multi-purposing.
Thanks,
John Vines
7line45>
> >
> > Thank you for adding this :)
I just copied the CloneIT... or BulkIT which had it.
- John
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.
to keep
> > the server APIs as stable as we can. You can keep the old bulkImport method
> > around and just call the new addFiles method in the implementation. This
> > will help us stay closer to compatibility across versions.
>
> John Vines wrote:
> This isn
ine180>
> >
> > I don't like removing the old bulkImport method. We should try to keep
> > the server APIs as stable as we can. You can keep the old bulkImport method
> > around and just call the new addFiles method in the implementation. This
> > will help us
7198/diff/
Testing
---
Includes CloneIntoIT, which exercises all permutations of the flags. Existing
BulkIT still functions as intended for validation of no feature loss in
refactoring exiting code for multi-purposing.
Thanks,
John Vines
t-patch. Hopefully
this works better
- John
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27198/#review58795
---
--
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27198/#review59201
---
On Oct. 29, 2014, 8:52 p.m., John Vines wrote:
>
>
On Oct. 30, 2014, 4:06 p.m., John Vines wrote:
> > I have only reviewed the FATE ops so far. How will this work w/
> > replication?
> >
> > I am thinking another possible approach may be to make a clone operation
> > that accepts multiple input tables and crea
s to reserve the table. If it succeeds it returns
> > 0, otherwise it returns 100. It should be called in isReady(), and
> > isReady() should return what it returns.
>
> John Vines wrote:
> CloneTable does it in the call space, as a heads up then
>
I was having issues with apache's mail forwarding.
I would have been +1. I don't consider adding a new api breaking it. It
would be nice to have the root synchronization of config updates settled,
but that was outside the scope of the ticket.
On Mon, Dec 1, 2014, 3:55 PM Corey Nolet wrote:
> +1
-1 I do not like the idea of committing to 1.7.0-1.9.9... API additions for
the 2.0 API. We have already come to the consensus that 2.0 will break the
1.x API which provides a lot of breathing room and freedom from old
decisions. This causes this issue to come roaring back and an even larger
amount
On Tue, Dec 2, 2014 at 3:14 PM, Christopher wrote:
> On Tue, Dec 2, 2014 at 3:07 PM, John Vines wrote:
>
> > -1 I do not like the idea of committing to 1.7.0-1.9.9... API additions
> for
> > the 2.0 API. We have already come to the consensus that 2.0 will break
> the
&g
Accidentally sent to just Shawn before
Sent from my phone, please pardon the typos and brevity.
-- Forwarded message --
From: "John Vines"
Date: Dec 3, 2014 10:01 AM
Subject: Re: [VOTE] API release policy for 1.7/2.0
To: "Sean Busbey"
Cc:
Sent from my phon
>
> On Tue, Dec 2, 2014 at 6:16 PM, Christopher wrote:
>
>> On Tue, Dec 2, 2014 at 5:18 PM, John Vines wrote:
>>
>>> On Tue, Dec 2, 2014 at 3:14 PM, Christopher wrote:
>>>
>>> > On Tue, Dec 2, 2014 at 3:07 PM, John Vines wrote:
>>> &g
wrote:
>
>
> On Wed, Dec 3, 2014 at 5:28 PM, John Vines wrote:
>
>> I stand by my -1. This vote would guarantee a level of API compatibility
>> that I don't think we should be held to.
>>
>
> Can you give some some specific reasons for your -1?
>
>
>
t 6:01 PM, Keith Turner wrote:
>
>
> On Tue, Dec 2, 2014 at 3:07 PM, John Vines wrote:
>
>> -1 I do not like the idea of committing to 1.7.0-1.9.9... API additions
>> for
>> the 2.0 API. We have already come to the consensus that 2.0 will break the
>> 1
I already cited sources for it in my previous response.
On Wed, Dec 3, 2014 at 6:57 PM, Christopher wrote:
> On Wed, Dec 3, 2014 at 5:28 PM, John Vines wrote:
>
>> I stand by my -1. This vote would guarantee a level of API compatibility
>> that I don't think we should
On Wed, Dec 3, 2014 at 7:02 PM, Christopher wrote:
> On Wed, Dec 3, 2014 at 6:48 PM, John Vines wrote:
>
>> It's hard to track this down-
>> http://www.mail-archive.com/dev@accumulo.apache.org/msg07336.html has
>> Busbey mentioning that 2.0 was breaking, whic
On Wed, Dec 3, 2014 at 4:06 PM, Josh Elser wrote:
> Can we bring the discussion back around? I feel like we have two separate
> things going on here.
>
> 1) Can we avoid further churn in the public API for [1.7.0,2.0.0] by
> avoiding any removal or additional deprecation.
>
Do you mean [1.7.0,2.
On Thu, Dec 4, 2014 at 8:15 AM, Sean Busbey wrote:
> On Dec 4, 2014 6:55 AM, "Josh Elser" wrote:
> >
> > (I was still confused so I just chatted with John on the subject of his
> -1)
> >
> > He was under the impression that it would not be feasible to leave the
> existing 1.X APIs in place with
Sent from my phone, please pardon the typos and brevity.
On Dec 4, 2014 11:20 AM, "Keith Turner" wrote:
>
> On Wed, Dec 3, 2014 at 6:48 PM, John Vines wrote:
>
> > It's hard to track this down-
> > http://www.mail-archive.com/dev@accumulo.apache.org/msg07336
On Thu, Dec 4, 2014 at 11:34 AM, Keith Turner wrote:
> On Thu, Dec 4, 2014 at 11:30 AM, John Vines wrote:
>
> > Sent from my phone, please pardon the typos and brevity.
> > On Dec 4, 2014 11:20 AM, "Keith Turner" wrote:
> > >
> > > On
On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner wrote:
> On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser wrote:
>
> > John Vines wrote:
> >
> >> Though I feel the biggest reasoning is our switch to semantic
> >>>>
> >>> versioning. And from semv
On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser wrote:
> John Vines wrote:
>
>> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner wrote:
>>
>> On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser
>>> wrote:
>>>
>>> John Vines wrote:
>>>>
>
On Thu, Dec 4, 2014 at 12:39 PM, Keith Turner wrote:
> On Thu, Dec 4, 2014 at 12:17 PM, John Vines wrote:
>
> > On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser
> wrote:
> >
> > > John Vines wrote:
> > >
> > >> On Thu, Dec 4, 2014 at 11:52 AM,
wrote:
> On Thu, Dec 4, 2014 at 11:11 AM, Josh Elser wrote:
>
> > John Vines wrote:
> >
> >> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner wrote:
> >>
> >> On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser
> >>> wrote:
> >>>
> >
opher wrote:
> On Thu, Dec 4, 2014 at 11:30 AM, John Vines wrote:
>
>> Sent from my phone, please pardon the typos and brevity.
>> On Dec 4, 2014 11:20 AM, "Keith Turner" wrote:
>> >
>> > On Wed, Dec 3, 2014 at 6:48 PM, John Vines wrote:
&g
Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0.
This is not something I encourage but I think this is something we should
have in our pocket just in case.
On Thu, Dec 4, 2014 at 3:56 PM, Keith Turner wrote:
> On Thu, Dec 4, 2014 at 12:59 PM, John Vines wrote:
2014 at 5:12 PM, Keith Turner wrote:
>
>
> On Thu, Dec 4, 2014 at 4:36 PM, Keith Turner wrote:
>
>>
>>
>> On Thu, Dec 4, 2014 at 4:00 PM, John Vines wrote:
>>
>>> Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0.
>>&g
[X]: adopt semver 2.0.0 (http://semver.org)
[ ]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[X]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[ ]: start oper
itted undecided, or "-1".
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Fri, Dec 5, 2014 at 1:51 PM, John Vines wrote:
>
>> [X]: adopt semver 2.0.0 (http://semver.org)
>> [ ]: adopt additional strictness to require documenting deprecati
I think there's an issue with this course of discussion because we're
discussion issues of our current 1.x release style while also discussion
Semver, both of which are incongruent with one another. Perhaps we need to
segregate adopting semver for 2.0.0 (which is waht I assumed), vs. adopting
semve
Just to make sure I'm understanding this before we get into another vote
thread kerfluffle, if we adopt semver in 1.7.0, include a new client api in
1.7.0, deprecate the old api in 1.7.0, then semver would allow (but not
require) removing the deprecated api in 2.0.0, correct?
On Mon, Dec 8, 2014 a
1 - 100 of 701 matches
Mail list logo
