Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: clarify that jira ticket is not mandatory

...

  • 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 will can take many many hours).
  • Have a JIRA. Changes must should be  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 changes 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 backwards backward-compatible , (with the exception of removing deprecated features. Removing deprecated features also , but this requires discussion).
  • Have backwards compatible messaging. Geode supports rolling upgrades on a live system. Message serialization and disk persistence Any changes must be backwards backward-compatible with previous versions. This includes algorithmic changes that don't affect the serialization format, including but not limited to messaging, disk persistence, and algorithmic traits. Geode has a framework for backwards 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.

...

In general, nothing can be removed or modified in way that is not backwards backward-compatible. If something is deprecated, it can be removed after a in the next major release, provided there is a after discussion on the dev list.  Backwards compatibility affects API's, client applications, and WAN clusters.  Support for rolling upgrades is another important consideration.

...

All public and internal APIs should have useful javadocs. For all public 
APIs (anything not in /internal/), new additions to the javadocs 
should include an a @since tag to let the users know when the feature was 
added. Eg

/**
   * Returns a collection of all of the CacheServers
   * that can serve the contents of this Cache> to clients.
   *
   * @see #addCacheServer
   *
      * @since 51.71
   */
  public List<CacheServer> getCacheServers();

Any feature which is deprecated should specify a link to the new alternative.

...

When writing code in a module which has a dependency on geode-core, the  Region.SEPARATOR and Region.SEPARATOR_CHAR constants should be used instead of hardcoded "/" characters in region names and paths.

...