Langfristige Releaseplanung für FreeBSD

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
Release Engineer Ken Smith hat eine grobe Planung bis Ende 2012 oder FreeBSD 10.1 aufgestellt. Bitte beachtet, dass dies bestenfalls eine grobe Annährung an die Realität sein kann:
As some of you may know the FreeBSD Project has been attempting to shift
over from "Feature based releases" to "Time based releases" as far as
trying to schedule them goes. Lets just say that's still a work in
progress (as in doing that with FreeBSD 7.0 didn't work out so well).

This is the schedule we will be shooting for through the next several
years/branches:

8/2008 7.1 and 6.4
2/2009 7.2
6/2009 8.0
8/2009 7.3
12/2009 8.1 and 7.4
3/2010 8.2
8/2010 8.3
12/2010 9.0
4/2011 9.1 and 8.4
10/2011 9.2
3/2012 9.3
6/2012 10.0
12/2012 10.1 and 9.4

No guarantees at this point, but those will be what we shoot for. I've
updated the releng page on the Web site to include the first couple of
those (commit was just done so it will take a little while to appear at
http://www.freebsd.org/releng).
Zum Vergrößern anklicken....

Interessant sind vor allem zwei Dinge. Es wird in Zukunft also wirklich die doppelte Überschneidung geben, welche schon mehrmals diskutiert wurde. Auf ein neues Hauptrelease folgen noch zwei weitere Subreleases des alten Zweiges. Nach diesem Motto kommt das schon öfter erwähnte 6.4 nun tatsächlich.
Außerdem schlägt sich hier nieder, dass FreeBSD zunehmend von featurebasierten Releases, wie es sie in der Vergangenheit gab, hin zu zeitbezogenen wechselt. Es soll also wirklich pro Zweig im Schnitt zweimal im Jahr veröffentlicht werden.
 
Ich mag zeitgesteuerte Releases. Denn erfahrungsgemäß fällt es sonst sehr schwer, einen Schlussstrich zu ziehen, weil immer irgendwelche wichtigen und tollen Features in Entwicklung sind. Auch das um eine Version verlängerte Legacy Release finde ich gut - dann kann man sich künftig überlegen, ob man mit x.1 oder doch lieber x.2 auf einen neuen Hauptrelease-Zweig migriert.
 
Die inflationäre Benutzung der Major-Releasenummern finde ich nicht so toll. Wenn man die Releases schon an die Zeit koppelt, kann man auch gleich die Release-Benamung vom Zeitpunkt ableiten.

Aber sonst prima, wieder ein Stück mehr OpenBSD in FreeBSD. ;)
 
Ich denke genau das rechtfertigt die Änderung der Major-Nummer. Die Inkompatibilität.
 
Zuletzt bearbeitet:
Kamikaze schrieb:
Ich denke genau das rechtfertigt die Änderung der Major-Nummer. Die Inkompatibilität.
Zum Vergrößern anklicken....
Wenn das gewünscht ist könnte man das Prinzip auch gleich richtig durchziehen und die Stable-Branches einstellen und einfach nur ein Release nach dem nächsten bringen, das jedes mal eine komplett andere ABI haben kann.

Irgendwie habe ich das Gefühl, dass man nach dem extrem langwierigen 4.x- auf 5.x-Prozess nun in das andere Extrem verfällt und bloß um diesen Fehler nicht zu wiederholen nun möglichst rasch und zeitlich gesteuert neue Major-Releases durchboxen will, unabhängig vom Stand der technischen Entwicklung. Ob das so gut ist?

Es muss ja nicht gleich wieder ein x.11-Release geben, aber ein Mittelweg mit x.6-Release oder x.7-Release statt maximal x.4-Release und dann wieder zur nächsten Major-Version hüpfen käme meiner Meinung nach dem Ansatz von FreeBSD als OS mit u. a. starkem Fokus auf Stabilität deutlich mehr entgegen. Nahezu jährlich ein neues Major-Release finde ich nicht so toll.

Ob's so gut ist, von einem Extrem in's andere zu wechseln?
 
Du vergisst dabei vielleicht, dass es so wie von 6.x zu 7.x auch von 7.x zu 8.x massive Änderungen gibt.

Die schnelle Release-Politik sorgt dafür, dass die technische Entwicklung nicht mehr so stark durch das Wahren der Kompatibilität gebremst wird. Das kann man gut oder schlecht finden aber FreeBSD befindet sich nun mal in einem großen technischen Umbruch.
 
Du vergisst dabei vielleicht, dass es so wie von 6.x zu 7.x auch von 7.x zu 8.x massive Änderungen gibt.

Die schnelle Release-Politik sorgt dafür, dass die technische Entwicklung nicht mehr so stark durch das Wahren der Kompatibilität gebremst wird. Das kann man gut oder schlecht finden aber FreeBSD befindet sich nun mal in einem großen technischen Umbruch.
 
Ja, ich bin mehr Freund davon, neue Major-Releases einzuführen, wenn es technisch sinnvoll ist, weil sonst die ABI gebrochen werden würde.

Eigentlich ist aber 7.x ein 6.x und die 6er-Reihe nur die Fortführung und Stabilisierung der 5er-Reihe. Trotzdem brauchte man compat und trotzdem musste man ein großes Upgrade inkl. neu-bauen aller Pakete durchführen, obwohl eigentlich auch ein kleines gereicht hätte.

Ich hoffe, dass die Realität die forsche Idee von jährlich neuen Major-Releases wieder deutlich einbremst. Ich glaube jedenfalls nicht so recht, dass so schnelle Major-Releasefolgen gut für FreeBSD sind.
 
Nun, auf der einen Seite möchtet ihr gern, dass Änderungen schnell eingehen. Z.B. möchten viele die Änderungen am VFS lieber heute als morgen. Auf der anderen Seite möchtet ihr aber auch lange Zyklen mit der daraus einhergehenden Stabilität. Das ist ein Zielkonflikt, der kaum zu lösen ist. Die Zyklen von ungefähr anderthalb Jahren sollen dem entgegenkommen.
Allen rechtmachen kann man es eh nicht, daher auch die zwei Releases aus dem alten Zweig, nachdem bereits das erste aus dem neuen erschienen ist. Wer äußerste Stabilität will, steigt halt erst mit X.2 in einen Zweig ein und nutzt ihn bis zum Ende, wer langen Support will, steigt bei X.0 ein und nutzt ihn bis zum Ende (hat dann gute 5 Jahre unterstützung), wer das neueste will steigt bei X.0 ein und wechselt auf den nächsten Zweig, sobald es ihn gibt... Alles in allem gibt es nun viel mehr Möglichkeiten. Auch die Kompatiblität soll verbessert werden, Symbol Versionierung wurde schließlich aus Gutem Grund mit 7.0 eingeführt.
 
Als User will ich natuerlich auch eher zuegig neue Major-Release um schnell in die Features von -CURRENT zu kommen. Andererseits kann ich dann auch gleich -CURRENT fahren (ist nicht so schlimm, wie es sich anhoert).

Als Firma hingegen, gefaellt mir das deutlich weniger, da jeder Major-Release einen riesigen Aufwand nachsich zieht. Bei mehreren Minor-Releases (nicht bis x.11, aber x.6 sollte schon noch drin sein) waere mir da wohler.

Bei uns ist der 6.x rollout noch nicht mal durch, und bald kommt das letzte 6.x Release :/
 
Für den privaten Anwender oder kleine Firmen und ihre Desktop-Rechner mag dieses Release-Verfahren i.O. sein. Man kann schnell entscheiden, ob man auf ein neues Release umsteigt, und kann den Umfang überblicken.

Sehr schade das aber FreeBSD jetzt die Apple- und Ubuntu-Gewohnheiten übernimmt. Man wird wie alle anderen auch. Und das ist aber nicht jedem Recht. Bei unserem Kunden (größter Autokonzern in Europa) wäre das ganze ein K.O.-Kriterium. Denn da zählt selbst bei Desktop-Rechnern langlebigkeit. Ich arbeite direkt beim Kunden, die stellen mir Rechner bereit. Ich habe bis vor ca. 2-3 Jahren dort noch auf einem WinNT4.0-Desktop entwickelt. Denn erst dann war im Konzern der Wechsel/Migration auf WinXP abgeschlossen. Win2000pro wurde einfach übersprungen. Vista wird auch übersprungen, denn die Migration würde wieder Jahre dauern. (einfach zu viele PCs und zu viele Individual-Software im Konzern)

Gerade das ist aber auch ein Erfolgsgeheimnis von Windows. (ja ja, auch wenn die OpenSource-Welt immer auf Windows rumhackt, muß man einfach fair bleiben) Nämlich beständigkeit und dauerhafte Kompatibilität den Firmen (vorallem Großkunden) anzubieten.

Wenn FreeBSD jetzt alle paar Jahre bewusste die ABI-Kompatibilität bricht, wird man zwar wegen neuer Features und Technologien die Freaks gewinnen, aber man wird sicherlich auch viele potenzielle Kunden verlieren oder erst garnicht gewinnen.

Es ist ein Gradwanderung. Ich kann es vom technologischen Standpunkt sehr gut verstehen, wenn z.B. Apple mal so ebend die Carbon-API fallen lässt. Aber Adobe muß dann halt ein Photoshop für MacOS X überspringen. Für normale Anwender verkraftbar, aber eine Katastrophe für Individualsoftware!

Mir persönlich als Heimanwender ist das egal. Ich freue mich zu Hause die neueste Technik ausprobieren zu können und damit zu spielen. Wenn das die Zielgruppe von FreeBSD sein soll, ist ja alles gut. :)
 
Ich denke auch, dass es gerade für große Businesses genau das falsche ist.

Debian ist ja gerade so beliebt, weil Debian-stable halt wirklich stable ist und lange hält. FreeBSD kann da nicht so glänzen. Es ist zwar stabil, aber die Versionierung ist totaler Murks. Für die Ports gibt es nicht mal Zweige, für alle Ports nicht Pakete....
Halbjährige Releases kann man denke ich nur machen, wenn 1) sehr viel manpower hat oder 2) die Releases nicht so groß sind oder 3) alte Releases sowieso kaum gewartet werden müssen, wie das bei OpenBSD z.B. der Fall ist.

Der neue Releaseplan sieht ja eigentlich nur Major-Releases mit Bugfixversionen vor.

ich bin wirklich kein Debian-fan, aber die haben das doch gut gelöst:
1) stable für long-term-support
2) testing für normale mensche
3) unstable für ungeduldige und devs

Wenn es die Technik dann wirklich erfordert macht man aus 2. ein 1. und aus 3. ein 2. Debian bietet dann sogar noch eine Weile old-stable support.

FreeBSD könnte das ähnlich machen (und sowas das früher ja auch ungefähr):
1) Releases für long term support
2) stable-branch für normale leute
3) current-branch für ungeduldige und devs

Stattdessen werden jetzt die Releases zu snapshots von stable und current wird fast jedes Jahr geforkt....
Naja... mal schauen was draus wird.
 
soul_rebel schrieb:
IDebian ist ja gerade so beliebt, weil Debian-stable halt wirklich stable ist und lange hält. FreeBSD kann da nicht so glänzen. Es ist zwar stabil, aber die Versionierung ist totaler Murks. Für die Ports gibt es nicht mal Zweige, für alle Ports nicht Pakete....
Halbjährige Releases kann man denke ich nur machen, wenn 1) sehr viel manpower hat oder 2) die Releases nicht so groß sind oder 3) alte Releases sowieso kaum gewartet werden müssen, wie das bei OpenBSD z.B. der Fall ist.

Der neue Releaseplan sieht ja eigentlich nur Major-Releases mit Bugfixversionen vor.

ich bin wirklich kein Debian-fan, aber die haben das doch gut gelöst:
1) stable für long-term-support
2) testing für normale mensche
3) unstable für ungeduldige und devs

Wenn es die Technik dann wirklich erfordert macht man aus 2. ein 1. und aus 3. ein 2. Debian bietet dann sogar noch eine Weile old-stable support.
Zum Vergrößern anklicken....
Naja, ganz so läuft das nicht ab. Die Pakete von unstable wandern permanent nach einer gewissen Zeit nach testing und zwar so lange bis ein Freeze ausgesprochen wurde. Und für mich (imho) glänzt FreeBSD in diesem Punkt mindestens genauso wie Debian. Für mich sogar mehr.

Aber das weicht jetzt wirklich vom Thema ab...
 
Moin,

angesichts des Release-Plans war es für uns eine gute Entscheidung, FreeBSD aus dem Programm zu nehmen. Alle 1,5 Jahre ein neues Haupt-Release, das beim Aktualisieren erheblichen Aufwand erfordert und damit - für den Kunden - erhebliche Kosten verursacht. Davon sind auch die Anwendungen betroffen.

So kann sich ein Betriebssystem auch unattraktiv machen.

So long

JueDan
 
Die Kunden müssen nicht alle 1,5 Jahre auf die nächste Release umsteigen, wenn sie nicht wollen. Es soll noch Maschinen geben, die mit 4.x oder 5.x laufen.
 
Eben. Wie ich oben schrieb, hat ein Zweig auch weiterhin mindestens 5 Jahre Unterstüzung. oder anders gesagt, letztes Release plus zwei Jahre. Das bedeutet Sicherheitsupdates und Ports. Und auch hinterher hindert mich nichts daran, einen Zweig weiterzunutzen. Neue Ports? Braucht man in 90% der Fälle eh nicht, wenn Kisten einmal ausgerollt sind, laufen sie einfach. Sicherheitsupdates? Ebenfalls meist irrelevant, weil sie selten Dinge treffen, die in einem spezifischen Anwendungsfeld auftreten können. Außerdem, aktuelle Software auf 5 jahre alten Kisten? Das ist eh ein Kompromiss, normalerweise fliegt der Kram gleich mit auf den Schrott und es wird neu begonnen...
Außerdem, dieser Thread zeigt mal wieder alles, wieso ich schon öfter in letzter Zeit dran dachte, mich hier zurückzuziehen. Denkt mal 2 Minuten nach. FreeBSD 1 lief von 1993 bis 1996. Da es spät im Jahr begann und früh endete, waren es etwas mehr als zwei Jahre. FreeBSD 2 lief dann etwa 2,5. FreeBSD 3 lief gerade eben mal 3 Jahre. Erst dannach ging man auf längere Zyklen, sofort schrie die halbe Welt auf "das könnt ihr doch nicht machen!". FreeBSD 4 lief dann 7 Jahre. Danach entschied man sich auf 5 Jahre zu gehen, was auch passierte. FreeBSD 5 lief von 2003 bis 2008. FreeBSD 6 läuft von 2005 bis mindestens 2010, eventuell (durch 6.4) auch noch länger. So, wo zur Hölle ist hier eigentlich das Problem? Hä? Wie man es macht, es ist auf jeden Fall falsch. Es kommt immer nur - übrigens immer von den gleichen, ewigen Nörgeln, die auch gern mal miterwähnen, dass sie gar kein BSD einsetzen, weil ja alles so scheiße und zum Kotzen ist - *nög* *nög* *nög*. Das nervt.

Was die ABI-Kompatiblität betrifft, die war bis jetzt auch nur innerhalb eines Zweiges gegeben und auch dort nur aufwärts. Also Auf 6.0 kompilieren und auf 6.3 nutzen geht, umgekehrt ist es nicht garantiert. COMPAT_X war schon immer ein Workaround. Mal ging's besser (5.x -> 6.x), mal schlechter (4.x->5.x). Hier ändert sich gar nichts. Die Situation wird eher besser, denn durch die Einführung von Symbol Versionierung gewinnt man dort viel mehr Spielraum. Siehe dazu auch hier: http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt

So, können wir nun bitte an die Arbeit zurückkehren?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben