Since we're not gaining by breaking compatibility in this case, I'd
first like to experiment / investigate the possibility of having a build
that allows the smart proxy's and existing Service API to be compiled
with target=1.4 and the rest of the build compiled with target=6.
After investigating the possibility of a solution, we can vote on the
issue then if you still feel strongly about it.
I was hoping someone already knew of a solution.
Peter.
Sim IJskes - QCG wrote:
On 09/15/2010 01:56 AM, Peter Firmstone wrote:
I don't want to have to answer user queries like: "I've set up a new
djinn group for my new Apache River nodes, but my existing Jini nodes
can't discover the new group. The new nodes are using my existing
programs and they work among themselves, but the new Registrars aren't
working with my older nodes. The new nodes services work with my old
clients only if they register with existing Registrars. Reggie seems
broken in Apache River 2.2.0?"
Why don't we just worry about creating a working River, and let the
compatibility issues be solved by the market? Most deployments are
done within the boundaries of a single organization. They should have
done this incompatible upgrade multiple times, it not something that
is unique to a river upgrade. Most bigger organizations will have
their own software-library, and establish their own software baselines
by cloning our vcs.
Keep compatible: -1
Gr. Sim
