-
-
Notifications
You must be signed in to change notification settings - Fork 41
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
Old releases support #194
Old releases support #194
Comments
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 |
👍 That makes sense to me, lets drop 2 |
Okay, so I think these are the action points:
|
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: