Versions Compared

Old Version 149

changes.mady.by.user Pierre Lasou

Saved on

compared with

New Version Current

changes.mady.by.user Tim Donohue

Saved on

Key

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

...

  1. Any changes must be compliant with the supported version of Java (e.g. for DSpace 7, Java 11 compliance is required)
  2. Your code must adhere to our Java Code Style Guide. Most major IDEs can easily import our Checkstyle configurations to ensure alignment with this code style.
    1. Your code should be well commented with Javadoc (required for all classes, public methods and larger private/protected methods).
  3. Your code must provide unit/integration tests for new features, bug fixes or improvements per our Code Testing Guide.
  4. If your contribution adds REST API endpoints or changes existing endpoint(s) behavior, you must submit a corresponding REST Contract Pull Request which documents the require changes.
  5. If your contribution adds new third-party tools or libraries, they must adhere to licensing requirements to be included. Refer to the Licensing of Contributions below
  6. User interface changes must use i18n keys to allow for easy translation to other languages (see the DSpace 7 Translation - Internationalization (i18n) - Localization (l10n) guide). At a minimum, please provide English text so that others may translate it.
  7. User interface changes should have a align with our User Interface Design Principles & Accessibility documentation. Primarily, this is a requirement for W3C WCAG 2.1 Conformance Level of "Double-A". 
  8. Your code must come with Documentation. Minimally, technical documentation must be part of the system docs – see Documentation Contributions below. Ideally, we'd also like User/Usage Documentation.
  9. Ideally, new features should be configurable (i.e. generalized so as to not be specific to one institution's needs/use cases).  Any new configurations should have sane defaults which can be overridden (as needed) in a site's local.cfg file.
  10. Add appropriate/useful logging to your code (ERROR, WARN, INFO, DEBUG, etc).
    1. Provide informative log statements and/or the entire Throwable exception. For example, "log.error('My custom error message', e)" is more useful than "log.error(e.getMessage(), e)"
  11. Where reasonable, retain feature/functionality backwards compatibility. This does NOT mean you have to create PRs for older versions of DSpace. But, it does mean that you do your best to keep in mind the behavior of features in older DSpace releases, and attempt to keep similar behaviors where reasonable. If there are questions/concerns about this, let us know. There are always exceptions.
  12. No database schema changes unless absolutely necessary to support a new feature. See Database schema changes below.
  13. If your code makes changes to the database schema or content, and you are patching more than one branch (for example, dspace-6_x and master), see Patching multiple branches below.

...