Currently a lot of our automation requires users to know how and what to do when making a PR, e.g. adding -draft to version, etc.
There's two points of improvements that can be made that should reduce the friction with creating PRs:
Schema Version Updates
Instead of relying on users to append -draft, we can have all versions on main be latest. When a release happens, it can look at the last release commit, and figure out what has changed, and assign the appropriate version at that time.
Also, this makes it much easier to consume main, if the version is always latest.
The biggest question here is how would the automation know what to bump in X.Y.Z? There's multiple ways to handle this, the first being a separate metadata file that can be updated to dictate what needs a X or Y bump. Z would just be default.
Another approach is since we are getting all things that changed between, release-commit..HEAD, we may be able to get the original PR and simply tag/label the PR as patch, minor, or major. I much like this approach cause it is strictly metadata at the github level, and doesn't require us to manage some file.
CDEvents GitHub Bot
Another pain point is whenever we do a patch release, this requires the user to create at least 2 PRs, depending how far the backport goes.
Instead, we can utilize a GH bot to have something like
@cdevents pick v0.4 which would automate in creating the backport, patch update branches.
Currently a lot of our automation requires users to know how and what to do when making a PR, e.g. adding
-draftto version, etc.There's two points of improvements that can be made that should reduce the friction with creating PRs:
Schema Version Updates
Instead of relying on users to append
-draft, we can have all versions onmainbelatest. When a release happens, it can look at the last release commit, and figure out what has changed, and assign the appropriate version at that time.Also, this makes it much easier to consume main, if the version is always
latest.The biggest question here is how would the automation know what to bump in
X.Y.Z? There's multiple ways to handle this, the first being a separate metadata file that can be updated to dictate what needs aXorYbump.Zwould just be default.Another approach is since we are getting all things that changed between,
release-commit..HEAD, we may be able to get the original PR and simply tag/label the PR aspatch,minor, ormajor. I much like this approach cause it is strictly metadata at the github level, and doesn't require us to manage some file.CDEvents GitHub Bot
Another pain point is whenever we do a patch release, this requires the user to create at least 2 PRs, depending how far the backport goes.
Instead, we can utilize a GH bot to have something like
@cdevents pick v0.4which would automate in creating the backport, patch update branches.