Branch cleanup

[lwilson]

Using a blank issue for this since it's not a bug or a feature request.

Problem

Omnia originally had 2 branches: main and devel. Currently, there are 30 different branches in the repo. Some of them are dead and could probably easily be pruned, others are active and I'm not sure why.

We really don't need to keep a lot of long-lived branches. We could even start merging everything into main and have only 1 active branch (especially when we move to break up the monorepo like @i3igpete discusses in #4847). But right now we have too many.

We need to take inventory of all of Omnia's current branches and decide what needs to stay (and why) and what can go. Anything that is stale and has no commits that haven't been merged back into main could go immediately.

There isn't any need for additional branches in the repo. Contributors should be following the CONTRIBUTING guidelines and develop in their own personal fork, not in a branch in the top-level repository.

Proposal

Delete Stale Branches

If there are no objections, we should immediately eliminate:

• All release-1.x (or release_1.x) branches
• All devel-1.x branches
• The devel branch

This would get rid of the vast majority of branches and should have no impact on existing development in the main branch.

Merge Commits and Delete Active Branches other than main

After these branches are deleted, we need to discuss merging any remaining commits/deltas from active branches into main via PR. Once that is done, all branches other than main should be deleted.

[abhishek-sa1]

Deleted devel branches. @lwilson @j0hnL @i3igpete Can we delete the release branches as well for 1.x releases?

[lwilson]

I'm good with deleting 1.x release branches. @j0hnL @i3igpete @sujit-jadhav any issues with deleting old release branches?

Strike my previous comment. It appears that some version tags were not tagged in the main branch. Instead, the tags were made in a release branch. For example, 1.7 was tagged in the release_1.7 branch instead of main.

I'm not sure how to resolve this. We could look back at the commit tree to see if we can identify a commit ID for each of these releases where they merged into main, but deleting the release branches will invalidate these tags that were made into non-main branches.

[lwilson]

Many of these releases have artifacts (zip and tgz files) attached to them, so someone could download the artifact for the version even if the commit ID goes away.

Early in the life of the project, we were creating release branches thinking there would be some concern about LTS. I think given how outdated the 1.x codebase is when compared with the current codebase, we should explore deleting the release branches and leaving the tags/artifacts so that someone can grab the tgz file associated with the release.

Going forward, we just need to always commit back to main, unless we intend to independently maintain multiple LTS versions (I would guess no, but it's really a question for @i3igpete).

[i3igpete]

I think LTS is out of the question, given the nature of how Omnia builds and deploys - we can't control if projects go offline. Doing so would require re-hosting and serving all of our dependencies (a la wayback machine), which is out of scope due to legal liabilities. That is why debug support is only for N-1 (and code changes only apply to N)