On Mon, Oct 6, 2014 at 5:12 PM, Mike Drob <[email protected]> wrote:
> I think before we can agree on a deprecation strategy, we need to firm up > the scope for this release plan. > > > What are the intentions for 1.7.0? Is it a "minor release" in the sense of > our previous minor releases, where we add a bunch of new features and > maintain some compatibility promises? Or are we going to try and make it a > truer minor release, where we cut down on the number of features and have > more conservative stakes in the ground? > > I'd imagine it'd just be like a 1.4->1.5 bump or a 1.5->1.6 bump. > Is this the same 1.7.0 that was going to be renamed to 2.0.0? Or an > intermediate release? > The idea is that not everything we wanted for a 2.0.0 label is ready and would warrant the version bump, but the current branch is getting mature, feature-wise, and would warrant a release. It probably isn't as big of a leap as previous versions in terms of raw number of features, but there's some big stuff in there (replication, for instance). So, maybe you could think of it as a release in terms of our 1.4, 1.5, 1.6 releases, but maybe slightly more conservative, since it doesn't have a ton of exciting new features. > When do we need to deprecate the mapred API if we plan to drop Hadoop 1 > support in Accumulo 2? (as has been discussed, but I'm not sure it was ever > formally decided.) > > Doesn't Hadoop 2 still have the mapred API not deprecated? I'd think we'd need to keep that still. > In general, I'm inclined to leave as much in as possible, and then if we > must remove things then do so in 2.0.0. I know that our compatibility > statement only promises one minor version, but that doesn't mean we have to > be strict at every opportunity. > > I'm okay with leaving more stuff in. There's just some specific stuff (see my reply to busbey) that is causing some headaches and I need gone. If we don't remove it in 1.7.0, I'll want to make a branch for 2.0 in which these things can occur. (which brings up another point... what do we want to do with master? Because, I wouldn't want to do 2.0 dev in master yet, and I don't want to mess up merges. I'll make a new thread for that.) > Mike > > On Mon, Oct 6, 2014 at 4:03 PM, Billie Rinaldi <[email protected]> > wrote: > > > Yes, we have both. Neither is deprecated. > > > > On Mon, Oct 6, 2014 at 1:56 PM, Mike Drob <[email protected]> wrote: > > > > > Do we still have mapred(uce) stuff? > > > > > > On Mon, Oct 6, 2014 at 3:54 PM, Christopher <[email protected]> > wrote: > > > > > > > The main thing I'm looking at which is causing problems for me is the > > > > instance.getConfiguration() stuff. It was never well defined, usually > > > > didn't work or do what was expected of it, and is still being > leveraged > > > > (incorrectly) by new code (replication, for instance, and I've > already > > > > informed Josh), because of > > > > ServerConfigurationUtil.getConfiguration(Instance instance). It > wasn't > > > > formally deprecated until 1.6.0, though. > > > > > > > > Aside from that, everything else is just a nice cleanup. A somewhat > > > > exhaustive list of what I was looking at was: > > > > > > > > Scanner timeout options > > > > extra batchwriter/batchdeleter factory methods > > > > some junk in MutationsRejectedException > > > > extra ZooKeeperInstance constructors > > > > securityOperations stuff from 1.5 > > > > extra getSplits and flush in tableOperations > > > > Constants.NO_AUTHS > > > > KeyExtents.getKeyExtentsForRange > > > > an extra Value constructor which copies from a ByteBuffer > > > > iterators that moved packages in 1.4 > > > > some protected getters in the mapred stuff > > > > unused RangeInputSplit in InputFormatBase > > > > LogFileKey/LogFileValue (old version) > > > > > > > > > > > > You can review the expected changes at > > > > https://github.com/ctubbsii/accumulo/tree/ACCUMULO-3197 (in two > > commits, > > > > one for instance stuff, the other for aggregators and everything > else). > > > > > > > > > > > > -- > > > > Christopher L Tubbs II > > > > http://gravatar.com/ctubbsii > > > > > > > > On Mon, Oct 6, 2014 at 4:11 PM, Sean Busbey <[email protected]> > > wrote: > > > > > > > > > No objection to removing aggregators. > > > > > > > > > > If anything first deprecated in 1.5 has managed to live this long > in > > > 1.7 > > > > > I'd like to keep it so folks have an easier time getting off of 1.5 > > > when > > > > we > > > > > EOL it. But I realize some things have probably already been > removed. > > > > > > > > > > On Mon, Oct 6, 2014 at 3:00 PM, Christopher <[email protected]> > > > wrote: > > > > > > > > > > > Re: ACCUMULO-3197 > > > > > > > > > > > > First: > > > > > > Any objections to finally removing Aggregators in 1.7.0? > > > > > > They've been deprecated in favor of Combiners since 1.4. > > > > > > > > > > > > Second: > > > > > > Is there any API deprecated in 1.6.x or earlier that you really > > want > > > > > > preserved in 1.7.0? > > > > > > (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for > > volume > > > > > > upgrades, at least.) > > > > > > > > > > > > -- > > > > > > Christopher L Tubbs II > > > > > > http://gravatar.com/ctubbsii > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sean > > > > > > > > > > > > > > >
