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
I have been thinking about our old releases, and I was wondering if we should:
Add EOLs to old plugin versions.
For example, 180 days after the next major version
Change the branch names to match the major version
For example, master -> 17.x, 16.x, and so on.
Releases
All releases should be very simple to publish via version control, to that end I think that release please should be configured with a target branch for each supported major version
Renovate
I was wondering if we should configure renovate for old release branches too?
The text was updated successfully, but these errors were encountered:
I'm open to 1, 3. all development should be on the main branch, and given the cost of maintenance, we will only back port important bugfixes or security fixes to previous branches. So, it doesn't seem too worthwhile to spend too much effort on the previous release branch.
re 2: do you mean renaming master -> 17.x. we will need to change the default branch to 17.x, 18.x... it sounds not a good idea. 😅
I have been thinking about our old releases, and I was wondering if we should:
For example, 180 days after the next major version
Change the branch names to match the major versionFor example,
master
->17.x
,16.x
, and so on.All releases should be very simple to publish via version control, to that end I think that release please should be configured with a target branch for each supported major version
I was wondering if we should configure renovate for old release branches too?
The text was updated successfully, but these errors were encountered: