...
- 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
<ticket><colon><space>followed by a concise summary line, then 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.
...