Skip to content

Implement full synchronization of version files #4865

@premun

Description

@premun

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No fields configured for Epic.

Projects

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions