coverlet-coverage / coverlet

Cross platform code coverage for .NET
MIT License
2.93k stars 385 forks source link

create draft release (triggered by master branch update) #1585

Closed Bertk closed 4 months ago

Bertk commented 5 months ago

This pipeline will reduce the effort for release documentation (#1579)

Chapters of release note are specified in configuration file .github\release-drafter.yml and PR labels are used to populate release note chapters.

Current label list of release-drafter.yml:

daveMueller commented 5 months ago

I think with release drafter we would be doing a fundamental switch on how we document our changes. Currently we focus on Github issues that we closed with our changes. But we don't reference the actual PR in the change log. Release drafter does this differently. It references PRs without an explicit reference to the issues a PR closes. This means for us we must be much more precise on the title of PRs and also start tagging our PRs.

Personally I like it when there is an issue to a PR because it contributes to transparency for the community. When I work in other open source projects I often wonder about commits that I can't link to an issue. Release drafter doesn't exclude this option as issues can still be linked to PRs, but we need to be more careful with our PRs.

I think release drafter looks interesting and we can give it a try. But we also need to document the workflow for creating PRs then. On the other hand, I don't think maintaining our manual change log is much work. Let's see what @MarcoRossignoli thinks about it.

Bertk commented 5 months ago

I used issues as a source for release notes in the past. We created software for a regulated environment and followed internal quality regulations. There was no PR without a issue with defined content. This is not required here and not all PRs need a issue e.g. maintenance/chore.

release drafter will create information based on PRs but you are allowed to ignore it.