Try shorter release cycles
Try shorter release cycles
Posted May 31, 2015 9:32 UTC (Sun) by zenaan (guest, #3778)In reply to: Try shorter release cycles by frnknstn
Parent article: PostgreSQL: the good, the bad, and the ugly
"Losing stability" is a misnomer - stability for those who care about it comes from feature testing in non-LTS releases combined with long term security and bug fix promises for the actual LTS release - 5 year stability in fact is what's provided currently, but unfortunately without the benefits of a high frequency feature-train broader/public "normal" release testing regime.
PostgreSQL really ought to read one of Corbet's Linux kernel statistics articles and take good notice of the incredible development and release velocity in action here. Yes PostgreSQL is different, in code, developers, layer in the stack etc, but the kernel release "model" works, and works incredi-firetruckingly well to the point it is mind boggling! Firefox seems to be doing alright too. LibreOffice has kicked off to an awesome start in its relatively young life.
The model works! and it works abundantly well.
The PostgreSQL team made a great move to a dvcs - git. This next step is needed to lift their game to the next level. I hope they see this sooner rather than later, and I do think their dev community is ready.
In Debian, those who want the latest go sid/"unstable" which is not only updated daily but is for any half-competent user, incredibly stable!
What we are achieving in different parts of our libre software communities is absolutely astounding, almost beyond belief. We truly live in a time of amazing software abundance and new feature velocity.
Those who want "real stability" in debian go "stable", which is an update every ~2 years, or if you stick with LTS as "oldstable" for a second LTS/stable cycle, you get around 4 years.
This matches rather well the 5-year LTS cycle currently provided by PostgreSQL.
And with more frequent "public feature train but non-LTS" PostgreSQL feature test releases, new features would get public exposure and the relative abundance of testers which is needed (the debian sid and bleeding edge gentoo crowd).
Combine this with an Ubuntu style "conservative" (say 3 months duration) cycle for each LTS release where risky or untested features are bumped to the next feature train release and even buggy features removed if needed for this LTS (to be added again in the next feature train release) we have ample evidence all over the large software project map that this must result in LTS releases with overall higher quality, better testing, more features and it's all more scalable for the developers involved.
Another 3-months and the feature train resumes...
<woo wooooo>
