Skip to content

Latest commit

 

History

History
54 lines (42 loc) · 3.54 KB

PULL_REQUEST_TEMPLATE.md

File metadata and controls

54 lines (42 loc) · 3.54 KB
Raw

See JENKINS-XXXXX.

See #XXXXX

Testing done

Proposed upgrade guidelines

N/A

Submitter checklist

  • The Jira / Github issue, if it exists, is well-described.
  • The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples).
    • The changelog generator for plugins uses the pull request title as the changelog entry.
    • Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during the upgrade.
  • There is automated testing or an explanation that explains why this change has no tests.
  • New public functions for internal use only are annotated with @NoExternalUse. In case it is used by non java code the Used by {@code <panel>.jelly} Javadocs are annotated.
  • New or substantially changed JavaScript is not defined inline and does not call eval to ease the future introduction of Content Security Policy (CSP) directives (see documentation).
  • For dependency updates, there are links to external changelogs and, if possible, full differentials.
  • For new APIs and extension points, there is a link to at least one consumer.
  • Changes in the interface are documented.

Maintainer checklist

Before the changes are marked as ready-for-merge:

  • Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
  • Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
  • Proper changelog labels are set so that the changelog can be generated automatically. See also release-drafter-labels.