Examining our release cycle: stricter instead of longer?
mah at jump-ing.de
Fri Jul 17 17:52:30 UTC 2009
Am 17.07.2009 um 10:00 schrieb Danny Piccirillo:
> [...] I just saw a story on Slashdot about OpenBSD's successful
> release process. [...]
While the SlashDot discussion merely shows people shouting without
thinking, the video is very interesting. If I understood it
correctly, OpenBSD does two things:
1) Keep every (official) development on the main trunk.
2) Swap between "add features, change API" cycles and testing cycles.
This appears to have several/surprising advantages:
- As there are no release branches, all people test the same food,
their own dogfood.
- Due to the large base of testers, regressions are exploited pretty
quickly, often within minutes.
- Accordingly, there's no need to run older releases.
- Each fix has to be distributed to one branch only, "backporting"
and/or "release engineering" is (almost) obsolete.
Now, while OpenBSD might be considered a bit exotic by many, another
successful project with a similar model comes to my mind: the non-
To be honest, I don't see the advantage of a strong emphasis on
"releases" either, as open source software is always a living thing.
Is it a matter of matching company policy checklists?
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
More information about the Ubuntu-devel-discuss