(Feature): Rename some branches

Make sure to follow our issue report guidelines

[X] I have read the feature request guidelines
[X] I have followed the contributing guidelines to the best of my understanding
[X] This feature is not on the issue tracker and is not a duplicate

Provide a description of your feature request

I'd like to propose returning to a "development on main and branch on release" type branching strategy since the current active branch names don't seem to follow this anymore.

Specifically I'd like to propose the following changes:

Rename RB-2.5 to main and keep it as the default branch. New development is done here.
Rename master to deprecated_do_not_use (or some other meaningful non-master name.) I don't know the history here, but it doesn't seem like this branch is actively developed anymore even though there appears to be a large number of commits. My thinking is to significantly deemphasize or delete this branch since it doesn't appear to be the desired direction going forward.
Create a RB-2.5 branch at whatever commit corresponds to the last released 2.5 build and only commit to it if we plan on doing another 2.5 release.
Delete RB-2.6 branch and just create 2.6 RC builds from main until we are ready to create an official 2.6 build. Branch RB-2.6 when we do an official 2.6 build and only commit bug fixes to that if we want to roll another 2.6.x build.
Identify and remove any stale branches that are no longer needed. I don't know the history here so I'm not in the best position to make these decisions.

Given that I'm new to the project, I'm sure there may be historical reasons for why things are the way they are. I also suspect there may be other tasks that need to be added to this list. I'm totally open to that. I just figured I'd try to start a conversation about this and see where it leads.

Is this a realistically implementable feature?

[X] My feature is realistically implementable
[ ] My feature is NOT realistically implementable

Can you contribute in creating this feature?

[ ] I am unable, or not willing to contribute to creating this feature
[X] I am able and willing to contribute to the creation of this feature

Additional details

No response

RB-2.5 should be a live version of what the next 2.5 release would be. We don't want to update it only when we make a new release. This is super useful to make eg pre-release builds or snapshots to test fixes. It's no use to have a branch that is only used to track the latest 2.5 release (Tags are used to mark releases)
I'm ok to rename master to something else. It has a completely different render engine (tile-based), which should be more efficient, unfortunately has hard-to-find bugs. It also has may architecture changes that enable features such as having nodes inside the viewer (think OCIODisplay)
main could be branched from RB-2.5 rather than a rename (which would break things and add overhead to fix these)
RB-2.5 should still be updated regularly. As soon as there are commits that are not compatible with RB-2.5 (eg Qt6 stuff), I find it better to commit changes that are OK to RB-2.5 and then do a merge commit on newer branches (eg RB-2.6). I would personally commit things to the current "live" branch (RB-2.5) rather than main, and then merge into main, for these reasons.

RB-2.5 should be a live version of what the next 2.5 release would be. We don't want to update it only when we make a new release. This is super useful to make eg pre-release builds or snapshots to test fixes. It's no use to have a branch that is only used to track the latest 2.5 release (Tags are used to mark releases)

So my thought was that this is what main would be for. My thought is that new releases are just tagged/branched off main. I think what I'm trying to understand is why it is desirable to have a version number in the primary development branch name. Most of my experience has been with repositories where primary development happens on main/master and branches are only created for releases that might require some sort of long term support (i.e. need version specific bug/security fixes).

I'm ok to rename master to something else. It has a completely different render engine (tile-based), which should be more efficient, unfortunately has hard-to-find bugs. It also has may architecture changes that enable features such as having nodes inside the viewer (think OCIODisplay)

Ok. Maybe rename it to something like "old_experimental_tile_based_renderer"? Do you foresee this work ever being picked back up?

main could be branched from RB-2.5 rather than a rename (which would break things and add overhead to fix these)

Fair enough. I was mainly just suggesting a rename because of the various changes checked into this branch since the last 2.5 release. I assumed that we wouldn't be doing another 2.5 release given the switch to Qt5.

RB-2.5 should still be updated regularly. As soon as there are commits that are not compatible with RB-2.5 (eg Qt6 stuff), I find it better to commit changes that are OK to RB-2.5 and then do a merge commit on newer branches (eg RB-2.6). I would personally commit things to the current "live" branch (RB-2.5) rather than main, and then merge into main, for these reasons.

So I don't really understand several things here. My intention was that main would be the "live" branch. It should always be in a shippable state and what a next release should come from. I assumed things like Qt6 changes would be checked in to main incrementally in such a way that it would NOT prevent a releasable build at any point. It seems like this would reduce the need for merging/double-committing.

RB-2.5 should be a live version of what the next 2.5 release would be. We don't want to update it only when we make a new release. This is super useful to make eg pre-release builds or snapshots to test fixes. It's no use to have a branch that is only used to track the latest 2.5 release (Tags are used to mark releases)

So my thought was that this is what main would be for. My thought is that new releases are just tagged/branched off main. I think what I'm trying to understand is why it is desirable to have a version number in the primary development branch name. Most of my experience has been with repositories where primary development happens on main/master and branches are only created for releases that might require some sort of long term support (i.e. need version specific bug/security fixes).

If "main" is the current development branch for a release that happens some-time-in-the-future (which is exactly what "master" was, when it was still active), where do we commit features that are common to that future release and to the current stable release?

Some repos have a "develop" branch for the more advanced and future-looking features that shouldn't be in the current release series, but I never found it to work well.

At least, with versioned branches, I know where to do my PRs:

RB-2.4 is for stuff that should work on Python 2 or 3 and Qt4 or Qt5
RB-2.5 is for stuff that should work on Python 3 and Qt4 or Qt5
RB-2.6 is for stuff that should work on Python 3 and Qt5 or Qt6

Then it's easy to merge RB-2.4 into RB-2.5 and RB-2.5 into RB-2.6 (I usually also merge RB-2.6 into RB-2). Everything "flows" naturally through the versions. Maybe that's not a usual way of handling branches, but it works super well for a repo that has 3 active branches and 3 developers.

If a branch is called "main", then should I do all my PRs on it and then cherry-pick stuff from main into RB-2.5, and different stuff into RB-2.6? That's a lot of work, and probably a big source of errors.

Honestly, I wouldn't recommend changing anything to the way branches are. "Don't break what works."

I'm ok to rename master to something else. It has a completely different render engine (tile-based), which should be more efficient, unfortunately has hard-to-find bugs. It also has may architecture changes that enable features such as having nodes inside the viewer (think OCIODisplay)

Ok. Maybe rename it to something like "old_experimental_tile_based_renderer"? Do you foresee this work ever being picked back up?

I think it should be archived and we should never ever commit anything to it. There's a few other things that we may want to backport from that branch, such as cute new icons and better looks for the GUI. You can check that out by building from it (if it still builds)

main could be branched from RB-2.5 rather than a rename (which would break things and add overhead to fix these)

Fair enough. I was mainly just suggesting a rename because of the various changes checked into this branch since the last 2.5 release. I assumed that we wouldn't be doing another 2.5 release given the switch to Qt5.

Qt5 was not much tested, so I expect at least two 2.5.x releases after we start releasing 2.6.0. This is what happened in the past, because most users don't test anything before release, so we will get buggy 2.6.0 and 2.6.1, but we will still want to release 2.5.1 and 2.5.2 with the latest fixes that are not related to Qt5. Remember, we are a small project. People know that 2.6.0 may have bugs, but if we call it 2.6.0-beta1, nobody will test it.

RB-2.5 should still be updated regularly. As soon as there are commits that are not compatible with RB-2.5 (eg Qt6 stuff), I find it better to commit changes that are OK to RB-2.5 and then do a merge commit on newer branches (eg RB-2.6). I would personally commit things to the current "live" branch (RB-2.5) rather than main, and then merge into main, for these reasons.

So I don't really understand several things here. My intention was that main would be the "live" branch. It should always be in a shippable state and what a next release should come from.

The main issue here is that there are sometimes two "live" branches, that is when the new version (eg RB-2.6) is not bulletproof enough to use in prod, so we still put as much fixes and enhancements into the previous release (eg RB-2.5). This is especially true because we are also distributing a large set of plugins, which have their own life (most bug fixes actually happen there).

I assumed things like Qt6 changes would be checked in to main incrementally in such a way that it would NOT prevent a releasable build at any point. It seems like this would reduce the need for merging/double-committing.

Yes that's the idea, but merging is so very cheap: when I start working on Qt6-specific stuff, I switch to RB-2.6 and merge in all changes from RB-2.5. That's just two clicks and no need to think about what you're doing

This was very helpful! Thanks for your patience in explaining it to me. I think the main difference between the 2 strategies is merging forward to new version branches vs backporting to old branches. Given the slow rate of change on this codebase, I suspect it doesn't really matter and the status quo works just fine.

I'll just close this for now. Thanks again for helping me understand.

NatronGitHub / Natron