...
Please ensure code changes:
- 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 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.
...