= ADR
https://adr.github.io/[ADR] stands for _Architectural Decision Records_ and is a way to capture architectural decisions over time.
This directory contains the ADR for the Quarkus _Core_ project.
== Proposing a new ADR
ADRs are contributed and edited using pull requests.
- Create an asciidoc (`.adoc`) document in the _adr_ directory named "n+1-my-adr-title.adoc", with n+1 the id. Use 4 digits as id (0001, 0002...)
- The document can be created by duplicating the _0000-template.adoc_ file. It is based on https://adr.github.io/madr/[MADR].
- The initial state of any ADR is _proposed_.
- Once written, open a pull request to drive the discussion. Add the `adr` label to the pull request, as well as any related area labels.
- Before merging the ADR pull request, update the state to _accepted_.
- Email mailto:https://groups.google.com/g/quarkus-dev[Quarkus Dev Mailing List] to inform everyone about the new ADR.
The discussion around an ADR happens on the pull request.
When the participant agrees, the ADR is marked as _accepted_, and the PR is merged.
Be sure that all the members impacted by the ADR have the chance to read it.
Typically, extension owners and knowledgeable people in this area should be involved in the discussion.
If the participants disagree, the ADR is rejected, the pull request is closed.
== ADR lifecycle
An ADR can have the following states:
- _proposed_ - Initial state
- _accepted_
- _deprecated_ - The ADR is not applied anymore or is out of date
- _superseded_ - Another ADR replaces the current one. The ADR is updated with a link to the replacement.
**IMPORTANT:** Once _accepted_, an ADR is immutable. Only its status and date can be updated.
All modifications must be done through pull requests:
* Deprecating an ADR should indicate the reason for the deprecation.
* Superseding an ADR should be done in the same PR as the replacement ADR.
1a815668fb