> I propose that the 2.x branch be treated like 2.x.y branches: as > long as there is sufficient volunteer labour, it should continue to > live. In order to avoid wasted development effort, it would be > prudent to announce that unless a 2.8 release manager steps up, > whatever is committed to the 2.x branch after the 2.7 release may > never get released. I think it's more difficult than that. It also takes developer effort to *commit* to the trunk. So if the trunk continued to live, would it still be ok if I closed a 2.x feature request as "won't fix", or only committed the new feature to the 3.x branch? As for old branches: they *don't* live in the way you claim (i.e. remain open with changes potentially just not released). Instead, at some point, they are frozen to bug-fix only, then to security-fix only, and then to no change at all. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4