I have a git repository with a long history. Releases were tagged along the master branch over time. If a user wants to go back and check out an old tagged release, they do not have the advantage of using an up-to-date build system or updated references to external data sources, licensing, etc.
The ideal end-goal is for the user to check out a tag, and have that point to a commit hash that links to an updated version of the old release with up-to-date build environments, pointers to external data, etc.
This is a widely used, multi-user repository.
I see three options, looking for recommendations:
release/branches that get updated but never merged back into master (low risk). Tag the head commit of that branch, and maintain as needed, deprecating maintenance for older versions.
git rebaseto rewrite history and bring updated older tagged releases back into master/develop, but out of temporal order (high risk)
- Do nothing, and provide an external solution to apply a patch when the user checks out an old tag.