> Android 15 introduced several complex changes under the hood... > Android’s move to trunk-based development, and the subsequent growth in size of Android’s QPRs (Quarterly Platform Releases) have made our job magnitudes harder! As a byproduct we must rebase our entire code-base every 3 months. > Sadly, Google also has a habit of introducing deprecations or outright removing code that older devices rely on with litt…
It should be the opposite, I am a bit confused about LineageOS' statement here. The Quarterly releases represent solid milestones towards the final Android number milestone. GrapheneOS claims that this made their rebasing much more efficient: instead of receiving a massive dump of all Android 15 at the end, developers receive incremental changes (the QPRs) to help them anticipate major changes in the code.
On the other hand, LineageOS runs a lot of devices at the very (lower) edge of compatibility, which means that (with Google pushing large changes quarterly instead of yearly) the build roster has to be reevaluated quarterly instead of yearly as well. This was not anticipated properly for the Android 14 (LineageOS 21) cycle, which resulted in 19 devices not being able to be built on a previously supported major version (and therefore dropping from the roster completely).
In addition, the components that have been causing rebase conflicts each year now have the opportunity to cause rebase conflicts multiple times a year.