Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Are Small Submissions should be for a single feature/bugfix, don't group submissions together
  • Are Green All code that is committed to Geode must pass ./gradlew build.precheckin
  • Have a JIRA Changes should should be associated with a ticket in jira
  • Are Discussed Changes that affect public API or introduce new features must be discussed on the mailing list. Geode is a mature product with many active users in production, so new APIs or features need to meet a high standard of quality. If a feature can be developed as an extension of Geode that may be more desirable - see Public APIs.
  • Have a backwards compatible API All changes to the public API must be backwards compatible, with the exception of removing deprecated features. Removing deprecated features also requires discussion.
  • Have backwards compatible messaging Geode supports rolling upgrades on a live system. Message serialization and disk persistence must be backwards compatible with previous versions. This includes algorithmic changes that don't affect the serialization format. Geode has a framework for backwards compatible serialization - see Managing backward-compatibility.
  • Follow Style Guidelines Code should adhere to the Code Style Guide.
  • Have tests New features must be accompanied by tests. Bug fixes should also include a test for the bug. See Writing tests.
  • Have few dependencies Avoid introducing new library dependencies when possible. Licenses for third-party dependencies must conform to Apache requirements.
  • Are Safe Geode is a heavily concurrent product. Code changes should be carefully considered with regard to thread safety and distributed system safety.