You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Our security policy states that we are maintaining the last two minor versions.
This is especially relevant for landing breaking changes on the master branch, without doing a release (or just doing a pre-release, for people to be able to try it out), and afterwards being informed about a security issue that has to be addressed.
This is the case while I'm writing it: the latest dist-tag (on npm) is pointing to 0.8.x, the next dist-tag is pointing to 0.9.0-beta.x and we still need to publish fixes to 0.7.x versions, since 0.9.0 has not been released.
Currently we are doing those fixes on branches following the naming convention release-0.7.x and release-0.8.x. But there is no github action workflow configured for those branches, and they are not protected in any way.
Since the current release process involves manual steps, especially for picking the version and updating the changelog, there doesn't seem to be a trivial way to automate the whole process.
We also often merge multiple PRs before we decide to publish a release, to safe time on the release process, but also to group features and fixes into a single release.
Describe the solution you'd like
Have fixed branch names for the versions we are supporting/working on, could be something like
latest for the currently supported version
next for the upcoming version while we are working on it
supported for the version that only receives security fixes
Automatic pre-releases when pushing to the next and/or the default branch.
by limiting it to pre-releases it is not impacting anybody that doesn't want to try the latest stuff
we could just use some 0.m.p-YYYYMMDDTHHmm-SHA as the version and not even update the package.json to ignore the whole topic of semantic release, committing back to the repo, etc
Add github workflow on latest and supported` branches, to make sure all checks pass.
Having this might give us some additional experience to fully automate the release process also for releasing the real version on those branches automatically
Notes:
I'm not sure to which degree we would still need those release-0.m.x branches, but we could still push to those, and once it's ready trigger a release by pushing that branch to the branches suggested above.
Would we switch the default branch from latest to next once we land the first breaking changes for the next version?
THe branch for 0.7.x doesn't even have the changelog and release scripts, so it might make sense to either merge it back in or wait until we no longer need to support it.
Describe alternatives you've considered
Continue doing all checks by hand
Additional context
Would be happy to learn from projects that have already done something similar. Have not done any research yet, please add information if you have some.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Our security policy states that we are maintaining the last two minor versions.
This is especially relevant for landing breaking changes on the master branch, without doing a release (or just doing a pre-release, for people to be able to try it out), and afterwards being informed about a security issue that has to be addressed.
This is the case while I'm writing it: the
latest
dist-tag (on npm) is pointing to0.8.x
, thenext
dist-tag is pointing to0.9.0-beta.x
and we still need to publish fixes to 0.7.x versions, since 0.9.0 has not been released.Currently we are doing those fixes on branches following the naming convention
release-0.7.x
andrelease-0.8.x
. But there is no github action workflow configured for those branches, and they are not protected in any way.Since the current release process involves manual steps, especially for picking the version and updating the changelog, there doesn't seem to be a trivial way to automate the whole process.
We also often merge multiple PRs before we decide to publish a release, to safe time on the release process, but also to group features and fixes into a single release.
Describe the solution you'd like
latest
for the currently supported versionnext
for the upcoming version while we are working on itsupported
for the version that only receives security fixesnext
and/or the default branch.0.m.p-YYYYMMDDTHHmm-SHA
as the version and not even update the package.json to ignore the whole topic of semantic release, committing back to the repo, etclatest and
supported` branches, to make sure all checks pass.Notes:
release-0.m.x
branches, but we could still push to those, and once it's ready trigger a release by pushing that branch to the branches suggested above.latest
tonext
once we land the first breaking changes for the next version?changelog
andrelease
scripts, so it might make sense to either merge it back in or wait until we no longer need to support it.Describe alternatives you've considered
Additional context
Would be happy to learn from projects that have already done something similar. Have not done any research yet, please add information if you have some.
The text was updated successfully, but these errors were encountered: