ChangeLog: Add a ChangeLog for Mbed Crypto #150
No reviewers
Labels
No labels
api-spec
bug
CLA requested
CLA valid
compliance
DO NOT MERGE
duplicate
enhancement
feature branch
good first issue
HEADER FORMATTING ISSUE
help wanted
Information
invalid
Jira status: AWAITING REVIEW
Jira status: CLOSED
Jira status: DONE
Jira status: IN PROGRESS
Jira status: IN REVIEW
Jira status: OPEN
Jira status: REOPENED
Jira status: RESOLVED
mirrored
mirror internally
needs: backports
needs: ci
needs: design review
needs: preceding PR
needs: review
needs: work
notabug
open for community contribution
Product Backlog
question
ready for merge
security
stale
type: bug
type: enhancement
type: question
web pages
wontfix
writing
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-ARMmbed/mbed-crypto!150
Loading…
Reference in a new issue
No description provided.
Delete branch "crypto-changelog-is-back"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The commit messages are not clear enough when something is worthy of
mention in the release notes. Re-add a ChangeLog file for Mbed Crypto,
with a different name from the Mbed TLS ChangeLog, to enable easier
merging from Mbed TLS to Mbed Crypto (for things like shared tool
updates).
If you're going to use the same structure as the Mbed TLS changelog, please use the same format. Making the changelog look marginally nicer when viewed through an interface that renders markdown isn't worth the added burden of coping with two different formats.
If we're going to use a different changelog format, let's switch to one that doesn't result in merge conflicts. Some projects such as Gitlab have switched to one entry per file, collected into a consolidated file when you make a release. How about doing this?
We can change the format because we don't expect to copy paste between the two ChangeLogs. This file even has a different name so no merges will happen between the two projects on accident. The only thing we could copy paste between ChangeLogs are tools changes (e.g. new feature in ABI checker), but we generally don't put those into ChangeLogs.
The move to markdown was to make turning a ChangeLog into release notes as easy as a copy paste, since release notes are markdown format already.
Looking at GitLab, "one file per entry, and then compiling the entries into the overall CHANGELOG.md file during the release process." sounds good to me.
We'll do ChangeLog a different way than this.
Pull request closed