Hi James,
sorry for dropping the ball on this. For the specific Jira I was working
on, I kept the old interface and introduced a new one that exposes more
functionality. I agree that this should be standard practice.
I opened https://issues.apache.org/jira/browse/TEPHRA-211 where we can
discuss s
Hi Andreas,
I don't think semantic versioning slows down development. It's just a
convention so that your consumers know more of what to expect. Were you
thinking of letting consumers know in some other way when wire
compatibility breaks? Just release note it (easy to miss)? Or just not
letting the
Hi James,
I am not sure how soon Tephra can establish semantic versioning. That
typically happens after a podling graduates from the incubator, and Tephra
has not had a 1.0 release yet.
In the mean time, I agree that we should try to preserve the compatibility
with older clients, but I would not
I meant that Phoenix can't pick up new Tephra releases that break wire
compatibility until Phoenix has a major release.
I'd vote for the new method approach with the old method being deprecated.
When you can remove deprecated methods is always tricky. IMHO, it'd be
great for Tephra to establish s
Hi James,
I assume you are talking about a major release of Phoenix. We do have to
anticipate that improvements and new features in Tephra will require Thrift
changes. So what would be the process to coordinate that?
- Does it mean that Tephra cannot make changes unless a major Phoenix
release is
Hi Andreas,
Phoenix can't assume that the client and server are the same version as we
support rolling upgrades for patch and minor upgrades. It'd only be ok for
a major release.
Thanks,
James
On Monday, October 17, 2016, Andreas Neumann wrote:
> Hi all,
>
> As part of https://issues.apache.org/
