Page History

...

Backwards Compatibility and Upgrade Path

Will the regular rolling upgrade process work with these changes?

By default, if the new geode.working-dir  property is not set, Geode will behave as it currently does. Users who do not set this property will experience no change.

If the user specifies a geode.working-dir other than the JVM's working directory, I do not know how  the effect on backward compatibility, the rolling upgrade process would be affected.

How do the proposed changes impact backwards-compatibility? Are message or file formats changing?

By default, if the new geode.working-dir  property is not set, Geode will behave as it currently does. Users who do not set this property will experience no change.

If the user specifies a geode.working-dir other than the JVM's working directory, I do not know how the backwards-compatibility would be affected.

Is there a need for a deprecation process to provide an upgrade path to users who will need to adjust their applications?

I believe that the only necessary change is to our documentation, so that if 

Prior Art

, and any shell scripts provided by either Geode or the user is TBD.

Prior Art

None known.What would be the alternatives to the proposed solution? What would happen if we don’t solve the problem? Why should this proposal be preferred?

FAQ

Answers to questions you’ve commonly been asked after requesting comments for this proposal.

Errata

What are minor adjustments that had to be made to the proposal since it was approved?None to date.