Well, I'm in two minds:
1. Suggesting it might help get generate discussion, perhaps finding
a migration path.
2. If there is no migration path, stopping any more developers from
being locked into Discovery V1, since it's easy for inexperienced
developers to do so. This forces forklift upgrades in deployed
environments, which itself introduces risk, either they upgrade,
may not upgrade at all, maintain a fork or choose some other
technology.
Possibly, one way to remove Discovery V1, is to make it only available
via a DiscoveryProvider, and removing it's use from methods, like
LookupLocator.getRegistrar() and substituting those with a
DiscoveryProvider read from configuration.
Then it could take a couple of releases to first deprecate, then remove
it, depending it's introduction into a djinn and how long the installed
nodes that require DV1 live on.
But I'm not even sure if that's possible.
If option 2 then we would be releasing River 3.0.
Peter.
Christopher Dolan wrote:
You're acknowledging that there's no upgrade path and that's a *justification*
for abandoning the old version? :-)
This change would motivate a bump in the major version number, in my opinion.
Previous threads on this topic:
http://mail-archives.apache.org/mod_mbox/incubator-river-user/201011.mbox/%3c77f1e32f67c8d5479858c0c7e93eb46503c2b...@wal-mail.global.avidww.com%3E
http://mail-archives.apache.org/mod_mbox/river-dev/201106.mbox/%3c77f1e32f67c8d5479858c0c7e93eb465072d9...@wal-mail.global.avidww.com%3E
http://mail-archives.apache.org/mod_mbox/river-dev/201108.mbox/%3c4e5a2c7d.2080...@zeus.net.au%3E
Chris
-----Original Message-----
From: Peter Firmstone [mailto:j...@zeus.net.au]
Sent: Friday, January 20, 2012 2:18 PM
To: dev@river.apache.org
Subject: Removing Discovery V1
Discovery V1:
1. I don't want new users using Discovery V1 by mistake.
2. No support for security.
3. No migration path to Discovery V2.
4. Problem for existing deployed environments.
5. Removal would simplify understanding of Discovery API's for new
developers.
Peter.
