How to handle batch patches

[pixelzoom]

From 9/26/19 dev meeting:

JO: How to handle sim patches on published release branches for general maintenance deploys.

Option 1: Detect during batch maintenance process, defer until sim is finished with RC test. Makes it difficult to published high-priority fixes.

Option 2: Change how we use release branches. Any change that requires QA must be done in a new release branch with a new minor number. Any change that can be published immediately without QA can be done in the existing branch. This ensures that the release branch is always in a state where the batch maintenance process can increment the maintenance number.

Option 3: Add an additional number to the version number, e.g. 1.0.1.1. Batch maintenance process would always increment this additional number. This would be a big (expensive) change to our build tool chain.

Option 4: Keep same version numbering. Batch maintenance process creates a branch off of the release branch based on shas for the current production version, reserves a maintenance version number, and adjusts maintenance number in release branch package.json. Patch needs to be applied to master, release branch, and branch off of release branch.

[pixelzoom]

@jonathanolson @jbphet and I discussed after dev meeting, did some whiteboarding, and consensus is that Option 2 is the best fit for PhET's build process. It will require some developer education, and some fail-safes in the maintenance toolchain.

[samreid]

With Option 2, we will have an abundance of release branches. Will the maintenance process maintain all of these, or does it only do the latest major or minor versions?

[jonathanolson]

With Option 2, we will have an abundance of release branches. Will the maintenance process maintain all of these, or does it only do the latest major or minor versions?

This would be good to discuss during dev meeting. I realize that phet-io uses the major.minor and assumes maintenance versions would keep those.

[ariel-phet]

Marking as a high priority since we should finish discussing this question

[jessegreenberg]

Discussion from 10/10/19:

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:

1. We need an automated tool for handling the reverting. This covers many things, @jonathanolson will pick this up.

[zepumph]

Does this still need to be marked for developer meeting?

[zepumph]

1. We need an automated tool for handling the reverting. This covers many things, @jonathanolson will pick this up.

I created #367 to handle this single task. Otherwise I believe we have a pretty good plan. Closing