Context
Right now, we do not allow any changes to the version files directly in the VMR.
The reasons are these:
- On backflow, we can't really use patches for version files. We need to read the version files in the repo and in the VMR (both before and after), add the packages that are part of the current build (and are in neither of these) and compile a set of updates we want to have in the files.
- Then take target branches' version file versions and update them with this mix (by handling the XMLs manually and updating the nodes).
- For forward flows, we try to just use git & take
--ours (the PR branches' version).
We do the above:
- so that on backflow we can add this third source of truth (the build itself) in the mix,
- and because if you open a PR and apply these, and a new commit would come from the VMR, git patches would break just because the version files already have the packages from the latest build so regular git operations are out of question.
So right now it's very asymmetric for the reason that the operations are also quite asymmetric (build assets are only on backflow).
Now consider changes to version files (like the complicated ones from MattT's PR) - how do they fit in this?
- If we make them in the repo, all is fine - because the version file updates during backflows will take that and inject the right versions only. So the file's other logic (like custom
Versions.props variables) will survive.
- On the next forward flow, this file will be more or less pushed into the VMR.
But this does not account for massive changes in the VMR. Because there's just no way to move those using git patches.
Goal
Figure out a way to allow changes on both sides and synchronize them safely.
Currently, we have agreed to do the following:
- Add
json versioning files global.json and dotnet-tools.json to the three way merge
- Split Version.props into two files: one for human organized ones, containing properties like
PreReleaseVersionLabel, etc.. and one for Maestro maintained ones
- Implement similar capabilities in forward flow updates
Context
Right now, we do not allow any changes to the version files directly in the VMR.
The reasons are these:
--ours(the PR branches' version).We do the above:
So right now it's very asymmetric for the reason that the operations are also quite asymmetric (build assets are only on backflow).
Now consider changes to version files (like the complicated ones from MattT's PR) - how do they fit in this?
Versions.propsvariables) will survive.But this does not account for massive changes in the VMR. Because there's just no way to move those using git patches.
Goal
Figure out a way to allow changes on both sides and synchronize them safely.
Currently, we have agreed to do the following:
jsonversioning filesglobal.jsonanddotnet-tools.jsonto the three way mergePreReleaseVersionLabel, etc.. and one for Maestro maintained ones