On Wed, Sep 2, 2015 at 6:12 PM, Darrel Schneider <[email protected]> wrote: > For backwards compatibility I see at least two levels of compatibility: > 1. client compatibility: can an old client work with a new server? > 2. code compatibility: can old code be used as is with the new product? > a. class compatibility: can I use my already compiled old classes/jars > with the new product? > b. source compatibility: can I use my already written code, after > recompiling it with the new product?
One of the very best things that I think we nailed in APR and Subversion was having a clearly-documented API and compatibility document. http://apr.apache.org/versioning.html http://subversion.apache.org/docs/community-guide/releasing.html#release-process As Geode has some downstream legacy users (due to Gemfire), while it could use this opportunity to change, it would be really good to be transparent about it as soon as possible - perhaps before the first incubation release is cut. It could be fine if Gemfire decides to maintain compatibility for its users in a specific set of libraries that aren't shipped with Geode (or even ALv2). Lots of different ways to go about it! -- justin
