Page History

...

• Are Small. Submissions should be for a single feature/bugfix, don't group submissions together.
• Are Green. All code that is committed to Geode should pass all PR checks (you can also run ./gradlew precheckin but this can take many hours).
• Have a JIRA. Changes must should be associated with a ticket in jira.  The initial commit must should begin with GEODE-nnnnn: <ticket><colon><space> followed by a concise summary line, then details on additional lines detailing what is being changed and why (see Commit Message Format).
• 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 backward-compatible (with the exception of removing deprecated features, but this requires discussion).
• Have backwards compatible messaging. Geode supports rolling upgrades on a live system. Any changes must be backward-compatible with previous versions, including but not limited to messaging, disk persistence, and algorithmic traits. Geode has a framework for backward-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.
• Are Secure. Geode should be secure by default.  Don't introduce new vulnerabilities or unsecured backdoors.

...