Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project releases #42

Open
WebFreak001 opened this issue Apr 9, 2020 · 0 comments
Open

Project releases #42

WebFreak001 opened this issue Apr 9, 2020 · 0 comments

Comments

@WebFreak001
Copy link
Member

With this issue I want to suggest a more uniform way of handling releases on dlang-community repositories.

Releases are a good way to attach additional information such as changelogs and release assets to tags. They can massively help third party developers understand what has changed since the last version they were using and what they need to change if they wish to upgrade to a newer version.

Having meaningful changelogs is key to improving the user experience for both applications and libraries. Application users can review what has changed and incorporate new features into their workflows and tools dependent on applications can update their logic. Library users and other packages depending on the projects can migrate to newer functions early on and know exactly what kind of new additions have been added and what kind of possibly previous hacks can be removed.

As we distribute dub packages using the git tags, using GitHub releases is already a very intuitive feature. Having releases as only tags is bad because they do not have any changelog attached and can not get any attached assets, so this should always be avoided. Previous project releases that only have tags should be annotated with release logs for clarity.

I think when creating new tags/releases it should always be necessary to:

  • create a release with the tag (on GitHub)
  • mention all fixed issues / merged PRs since the last release
  • list relevant commit titles
  • list breaking changes
  • list new APIs

Additionally I propose we should:

  • use a consistent format (like having some "Bugs", "Improvements", "Features", "Changes" sections)
  • when releasing full releases, copy over logs from all pre-releases for that version
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant