accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Deprecation removal for 1.7.0
Date Thu, 09 Oct 2014 00:56:22 GMT
Sure. Let's say that for Accumulo version 1.7 we decide to introduce feature
set A. Feature set A requires no client api changes. For version 1.8 we
decide on feature set B and one of the features requires a client api
change. We have a user that is currently on version 1.7 and wants a feature
from feature set B, but is unable to upgrade to version 1.8. To achieve this
someone would need to take the feature from version 1.8 and apply it to a
patch release of version 1.7, porting the feature backwards to a previous

-----Original Message-----
From: Jeremy Kepner [] 
Sent: Wednesday, October 08, 2014 7:31 PM
To: dlmarion
Subject: Re: Deprecation removal for 1.7.0

Can you clarify what "backport it" means?

On Wed, Oct 08, 2014 at 07:16:28PM -0400, dlmarion wrote:
> Personally I think this discussion is headed in the wrong direction. I
would suggest picking a release numbering policy. Then, develop the features
for the release and adjust the release number based on the client api
changes caused by the changes in the release. If someone needs a feature but
cant afford the client api change, then try to backport it. We should try to
move forward.
> <div>-------- Original message --------</div><div>From: Adam Fuchs

> <> </div><div>Date:10/08/2014  6:55 PM  (GMT-05:00)

> </div><div>To:,Jeremy Kepner 
> <> </div><div>Subject: Re: Deprecation removal for
</div><div> </div>What's the right level of review? Should we have a public
announcement board of some sort on the website, or is a request for comment
on the user list sufficient?
> On Wed, Oct 8, 2014 at 5:35 PM, Jeremy Kepner <> wrote:
> > Perhaps the process should be changed to require review prior to
> > We can't assume all our users are always scanning the e-mail list.
> > It is a reasonable expectation that we won't break their code.
> >

View raw message