Update release process #315
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adapt RELEASE.md for new release process, also taking into account pub.dev releases
|
btw: I also have a branch with release notes for the next release that may just need some slight updates for my recent housekeeping PRs |
Merged
JulianBissekkou
approved these changes
Nov 13, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I think we should make a new release, both because it has been quite some time since the last release and we have collected a lot of changes and new features since then. Also this allows us to fix #309 by fixing the packages released on pub.dev
So I thought a lot about the release process and came up with this proposal.
It may seem a little complicated at first, but I think it's actually not much work.
The most labor-intensive step is usually the changelog. So we might want to pay attention to updating that one with every relevant PR in the future.
I would keep the git releases for the time being, because a) we haven't officially announced/started releasing on pub.dev, so most users will use the plugin from git and b) because the pub.dev releases aren't fully functional, yet.
If we get the pub.dev releases right, we could make those the official recommended way of using the plugin and in the future discuss removing the "intermediary" git-release step.
For the last step: I would like to set up automated publishing to pub.dev (see https://dart.dev/tools/pub/automated-publishing#publishing-packages-using-github-actions). I think it both reduces the amount of work and increases the transparency and supply chain security for plugin users, compared to uploading the plugin from someones personal workstation, because it is clearer that the uploaded version is actually the unmodified one from GitHub (as long as one trusts the GitHub actions runners).
I also removed the previously contained step of commenting out dependency_overrides (which are very useful for us contributors), because according to the dart docs they are always ignored for packages from pub.dev (and generally for any package your application depends on). So it would be unnecessary work to remove them. (https://dart.dev/tools/pub/dependencies#dependency-overrides)