Open zepumph opened 1 year ago
Tagging @pixelzoom as something to note here as he may be using the maintenance tooling for publishing his upcoming sim suites (gas-properties and faradays-electromatic-lab).
It WOULD be better if we had consistent support for this.
I end up just cherry-picking directly to the release branch (e.g. gas-properties), and then use the automated MR processes for diffusion. It hasn't been clean, but it works.
Right. That is how we did Build A Nucleus last year too. I believe this is pretty much the main item keeping wider adoption of this tooling across the dev team for deploying sims. I'll track down the bug.
@chrisklus and I are trying to go all in on using the MR process software for the 1.1 release of Number Play. So for it has been amazing, but we hit one snag when trying to cherry-pick commits into
number-play/
itself (the 1.1 branch). It isn't clear if this is even supported, but we thought it best to reach out to @jonathanolson to talk this through.We wrote these lines of maintenance release code:
And then found that it created a
number-play-1.1
branch in number-play and applied things there. In this particular case, the fixed github issue had three commits, 2 in common code and then this one in the release branch, so for organization it would be nice to have the same process.@jonathanolson, how do you feel about supporting this? In general, @chrisklus and I like the idea of using the MR process for all commits, though we could also just as easily cherry pick manually into the release branch itself.
The proposed fix is basically if a needed-patch repo matches the patch repo, then we should use the release branch schema (1.1) instead of the dependency branch schema (number-play-1.1).
For example, if you needed to fix gas-properties, and it had to apply to its 1.1 branch AND to diffusion (a subset sim), then a command like this would be needed:
But here gas-properties should gain only the
diffusion-1.0
branch, and the fix for GP 1.1 would just go right onto the 1.1 branch.