Examining our release cycle: stricter instead of longer?

[Markus Hitter]

Am 17.07.2009 um 10:00 schrieb Danny Piccirillo:

> [...] I just saw a story on Slashdot about OpenBSD's successful  
> release process. [...]
>
> http://tech.slashdot.org/story/09/07/16/2322203/Why-OpenBSDs- 
> Release-Process-Works
> http://www.youtube.com/watch?v=i7pkyDUX5uM

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- 
emulator Wine.


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?


Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/