We are going to have a period of time (at least 6 probably 12 months where we will need to merge the majority of applicable fixes back into Joomla 3.8 tbh). For the remaining 12 months (to take us upto the documented two years) I agree we'll tail into critical bugs then security fixes only. However to merge bugs it's probably going to be easier to merge bug fixes into 3.x and then merge those fixes into 4.x rather than the other way around. Because Joomla 3 will be behind the Joomla 4 branch.

You should never be porting stuff between branches. Follow Symfony as an example, all patches are merged to the lowest applicable branch based on a version's support state and the maintainers then forward merge the branches (so 3.7 into 3.8 into 4.0).

Do NOT repeat the mistake of maintaining 2.5 and 3.x where every patch had to go through testing as two separate items on two different branches. In essence you're maintaining two different projects on one repository at that point, unacceptable.

I would also not suggest turning 3.x into a "maintenance mode only" as soon as 3.7 is tagged. Unless 4.0 is in a state to enter beta at that point, that's just indicating to me there are resource and management problems. 3.x should continue to get full attention (at least for all bugs) with regular maintenance releases until such a time that its support does transition into security or high importance items only.

The Bootstrap approach pissed off a lot of people. IMO they killed their 3.x branch too early because of a lack of focus and resources. Don't repeat that here.

And for the sake of all that is sane, someone publish a roadmap for this release with a real plan that is going to be stuck to otherwise in 6 months we'll be starting on 4.0 v4.

What Michael said.

If you turn 3.x into maintenance mode, you can't release a 3.8 anymore. Maintenance means no new features anymore, only bugfixes which is only patch releases.

Also, according to our dev strategy you need to announce the latest planned minor release 6 months in advance so extension developer and users know what will be up.

There are should be a sane period between something got deprecated and removed. I'd suggest at least 6 months here, if not more. Otherwise the deprecation will be a bad joke as extension developers will have no time to adjust their code.

Releasing a 4.0 close to the last planned minor (eg 3.8) is not an option, especially not if 3.8 will contain the deprecations for 4.0. And of course 3.8 has to be released before 4.0. Removing stuff in 4.0 and backporting the new and deprecating the old stuff to a 3.8 which is released later just doesn't work.

So imho the only way is to announce now that 3.8 will be the latest minor release which is released around next summer. Main development still takes place in that branch and there also can be new features in it. Needed deprecations and stuff that helps upgrading to the planned 4.0 can go into that one. After 3.8 is released, 3.x is going into maintenance mode, accepting no new deprecations, no new features, only bugfixes. Branches are switched at that point, the current 4.0-dev will be merged into staging and staging will be copied to a new 3.7 branch.
If you want to do stuff in 4.0 which there is no time for proper deprecation and "backporting" before, please, and I mean PLEASE postpone it to 5.0.

4.0 should be in a development state for at least another 6 months by then. Because I can assure you, that there will be enough work still at this time to get it to stable. You will also only then get enough testers and extension developers to test your new architecture. Don't hurry that release.

every patch had to go through testing as two separate items on two different branches

My intention for the proposed roadmap was, not to have that situation.

Also, according to our dev strategy you need to announce the latest planned minor release 6 months in advance so extension developer and users know what will be up.

I wasn't aware of that, where is that documented? So we should then announce 3.8 as latest minor release in the 3 series, when we want bring 4.0 on the horizon.

After 3.8 is released, 3.x is going into maintenance mode, accepting no new deprecations, no new features, only bugfixes. Branches are switched at that point, the current 4.0-dev will be merged into staging and staging will be copied to a new 3.7 branch.

That was exactly the procedure I was describing, just a bit earlier.

All clear for me now.

I wasn't aware of that, where is that documented?

From https://developer.joomla.org/cms/development-strategy.html:

The PLT will give at least 6 months notice of the estimated last minor release in a major series. This notice will be part of the roadmap as a soft target date of the final minor version release.

That was exactly the procedure I was describing, just a bit earlier.

The "earlier" part was the problem ?

I know now.