+1 We should definitely produce a table similar to that with version/compatibility information.
On Wed, Sep 2, 2015 at 5:34 PM, Justin Erenkrantz <[email protected]> wrote: > 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 > -- William Markito Oliveira Enterprise Architect -- For questions about Apache Geode, please write to *[email protected] <[email protected]>*
