If they are small GUI updates changes great - but why the API? I guess it would be easy to maintain and update any tools without much of a hiccup if anything in GUI updated. If there is a lot of GUI with API changes - you could toggle it with the legacy method in the experimental user prefs and eventually use the new GUI and API without much of a hiccup. If there is a new UX with new API, then yes, you should merge in the new method with the old method for adaptability for a point release cycle, not just master dev cycle. But minor GUI updates wouldn’t need this no?
How much cleaning do you plan to do? Is it an entire refactor? Maybe this type of backwards compatibility would be irrelevant if it’s GUI updates only. Maybe it’s not even invasive at all.
Other notes
Though, on a side note, the studio here cannot afford to use LTS branches (or any other branch other than the main trunk) due to the required features and bug fixes in master to get the job done - bleeding edge often is the only way (ei, using Apply Attributes to get UV’s fron GN for game assets in the GUI that came out this month), and we cannot fork the LTS branch because we have to merge and use every master update per week to keep code tidy, up to date and relevant - and future-proof our own builds - it is less overhead and easier to merge a single conflict resolve and maintain if from our master with your master this way. If we diverge from master more than a few weeks, the code and ability to merge in any new features into our own deployment is eventually unsustainable (or too big to do in a single chunk). We have to fork or branch from trunk to stay relevant, so far has worked for over 5 years now.
In general though, by planning the API to be future proof with flexibility to work around labels and socket index in the GUI and to allow new features - if additive also - there would be no problem. Legacy code or API can be phased out over time - as long as the trunk API which allows GUI updates is solid meanwhile. On the surface, GN with 3.0 felt like it had the necessary overlap with the “Legacy Nodes” option to work - though some addon still broke.
This is where official gitflow becomes sorely lacking when using the trunk with other studios or internal builds - since the trunk here in the Blender Foundation is the development branch, this makes these API changes much more evident since any studio that forks from the trunk will inherent shifting instability over time as experimental code gets tinkered with. And forking a branch is not future proof specially with the hundreds of commits we sometimes get per week to merge in and make sure it doesn’t step on any toes we develop in our own master, this is an engineers sometimes full time job.
Ideally any API development and breaking changes should be developed in a branch away from trunk to then confirm if it really will/should break anything before pulling into master, then it gets merged close to official release dates with a smooth time to update a pipeline that uses the trunk (and may encourage addon devs to develop in the stable master). But… as it stands, for a stable development trunk, to keep the trunk solid, some extra effort for compatibility with official release branches and their API would be coded in with overlap - and yes, that would be a pain over 2 years. It’s a bit of a chicken or the egg debate… Thanks for reading though!
I see “API change” and get ptsd from when thirdparty addons broke in the pipeline due to this happening elsewhere (not shader nodes).