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
We talked about a different option from the original list. Instead, we are going to try a process change where when we encounter the case where a release branch has changes that have not yet been published, we decide whether or not to revert the changes and add back after a batch maintenance release or publish the maintenance release changes on top of them. This gives us the most flexibility without the challenges of changing version numbers or other aspects of our process. One drawback that was mentioned was that the maintenance versioning numbers could get confusing. For example, consider that you have a change sitting on 1.1.1-rc.1 that gets reverted for a batch maintenance patch that goes on 1.1.2-rc.1. The decision is that 1.1.1 will be dropped forever. The reverted changes will then go on 1.1.3-rc.1. This drawback was acceptable given the other considerations.
We are going to try this for now. If it becomes too troublesome we will revisit and investigate a more intensive change later.
TODOs for the future:
We need an automated tool for handling the reverting. This covers many things, @jonathanolson will pick this up.
So I'm promoting this TODO item to a new issue, and closing the other. I don't think this is too high a priority, but may be useful to add on a rainy day in case we every have a VERY HIGH priority MR that needs to go out in a matter of hours or days.
The text was updated successfully, but these errors were encountered:
From #151 (comment):
So I'm promoting this TODO item to a new issue, and closing the other. I don't think this is too high a priority, but may be useful to add on a rainy day in case we every have a VERY HIGH priority MR that needs to go out in a matter of hours or days.
The text was updated successfully, but these errors were encountered: