Currently, adding a changelog entry is done by appending a TOML section to .changelog/_unreleased.toml. However, this directly leads to merge conflict when MRs are opened concurrently.
This can be partially mitigated by inserting the new changelog entry at a random point in the file, instead of appending to the end. However, this is only possible when the file already contains multiple entries, and the probability of conflict is still high.
A more robust solution would be to have a _unreleased/ directory instead, and creating a new file for each entry. The file name could be either be chosen arbitrarily by the contributor (with a non-negligible chance of collision), or use the UUID from the id field. The files could then be optionally sorted, and merged together for a new release.
Currently, adding a changelog entry is done by appending a TOML section to
.changelog/_unreleased.toml. However, this directly leads to merge conflict when MRs are opened concurrently.This can be partially mitigated by inserting the new changelog entry at a random point in the file, instead of appending to the end. However, this is only possible when the file already contains multiple entries, and the probability of conflict is still high.
A more robust solution would be to have a
_unreleased/directory instead, and creating a new file for each entry. The file name could be either be chosen arbitrarily by the contributor (with a non-negligible chance of collision), or use the UUID from theidfield. The files could then be optionally sorted, and merged together for a new release.