You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's imagine that the latest number in the ADR numbering sequence is 5.
Dev A creates a PR with an ADR (he/she denotes that ADR with number 6).
Dev B creates a PR with an ADR (he/she denotes that ADR with number 6).
Dev A and Dev B merge at a different point in time.
Now we have two ADRs with different names but the same number.
One possible solution is to have a lock file that would contain the last number. We would have to increment this number each time we create a new ADR. This way after Dev A merges, Dev B can't merge due to conflict that needs to be resolved.
The con of this solution is that a Dev may forget to modify the lock file.
Are there any other propositions on solving this issue?
The text was updated successfully, but these errors were encountered:
One of the solutions is to use dates instead of sequence.
The date can be in the filename prefix or it can be in metadata (e.g. file header or commit metadata)
That would solve the case of concurrent (long-live) branches.
An alternative way is to use an external sequencer (e.g. a dedicated branch in the repository), so the sequence is global for all PRs across all branches. However, then sequence number allocation becomes an API call.
Let's imagine that the latest number in the ADR numbering sequence is 5.
Dev A creates a PR with an ADR (he/she denotes that ADR with number 6).
Dev B creates a PR with an ADR (he/she denotes that ADR with number 6).
Dev A and Dev B merge at a different point in time.
Now we have two ADRs with different names but the same number.
One possible solution is to have a lock file that would contain the last number. We would have to increment this number each time we create a new ADR. This way after Dev A merges, Dev B can't merge due to conflict that needs to be resolved.
The con of this solution is that a Dev may forget to modify the lock file.
Are there any other propositions on solving this issue?
The text was updated successfully, but these errors were encountered: