Entwicklung Firefox

http://www.squarefree.com/burningedge/20…7-trunk-builds/

Und nun ganz offiziell [1]. In Abweichung zur bisherigen Verteilung über die Channels werden diese um einen *Alpha-* Channel erweitert.

Nightly-Channel = mozilla-central (täglich)
Aurora-Channel = mozilla-aurora (Alpha, 6 Wo von mozilla-central)
Beta-Channel = mozilla-beta (Beta, von QA abgenickt, Beta-User)
Release-Channel = mozilla-release (Release, Publikum-Auslieferung)

Eine augenscheinliche Kennzeichnung erfolgt über neue Logos [2].

[1] https://developer.mozilla.org/devnews/index.…rapid-releases/
[2] http://mozilla.seanmartell.com/engagement/logos-v2.png

... wie die bisherigen auch schon! :mrgreen:
Denke ich mal...

(Also Zuweisung, URL ...)

http://christian.legnitto.com/blog/2011/04/0…ging-next-week/ ff

Der Zweig mozilla-aurora ist zunächst aus dem Boden gestampft. Das Building des 1-ten Aurora ist erfolgt [1]. Der Channel steht auf Aurora. Der Rest - nach 1-tem Querlesen - ist logischerweise noch Nightly! Es stehen mom. noch einige die Versionierung betreffenden Bugfixes aus. So sollen sich die künftigen Builds auch durch ein eigenes Background-Images bei dem AUS-Update unterscheiden [2].

Hier wurde ein entsprechendes Profil zumindest für AUS vorbereitet. So auch durch Hochsetzen der entsprechenden Kompatibilität- Schalter :lol: .

UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110411 Firefox/4.2a1pre ID:20110411163048

[1] http://hg.mozilla.org/mozilla-aurora/rev/b70744835d94
[3] https://bug648362.bugzilla.mozilla.org/attachment.cgi?id=524587

Zitat von ChrisFOX

- wieso gibt es jetzt auch euch eine Aurora version?

Das hat zum einem mit der angestrebten Straffung des Entwicklungsprozesses zu möglichst unverrückbaren Terminen und zum anderen mit dem damit verbundenen gleichzeitigen Pushen von Entwicklungsstufen zu tun. Ich sehe das unabhängig von Versionsnummern durchaus positiv, da dies bei entsprechenden Augenmerk auch Auswirkungen auf die Qualitätskontrolle haben könnte.

Ausgangspunkt ist der Entwicklungsstamm - Trunk. Nach erfolgter Eingrenzung von Entwicklungszielen verzweigt daraus zum Termin eine Alphaversion - Aurora-Channel - der aktuell angestrebten Version. Gleichzeitig wird im Trunk die Entwicklung zur nächsthöheren Stufe fortgeführt. Diese wiederum zweigt zum festgelegten Termin wieder in ein Alphastadium - Aurora-Channel. Die in der Alphastufe liegend Alpha der Version zweigt zu diesem Termin in das Betastadium - Beta-Channel.

Nachdem aus dem Stamm eine weiteres Entwickungsbuild in die Alphaebene gehoben wurde, wird die bisherige Alpha zur Beta und die Betaversion geht in das Release - Release-Channel.

In diesem Modell sollen die Termine das Primat haben. D.h., werden in den festgesetzten Zeiträumen einzelne Ziele (Features, Verbesserungen) nicht erreicht, dann gehen diese in die nächste Entwicklung ein.

Im Alphabereich sind die Features, Veränderungen u.ä. weitestgehend beinhaltet und es erfolgen nur nur kleine Änderungen. Im Betabereich geht es vornehmlich im das Austesten der Version, der Feststellung von Fehlern aller Neuerungen. Features werden nicht mehr eingearbeitet. Mit der Freigabe gehen Versionen für die publikumswirksame Auslieferung in das Release.

Daran ist erkennbar, dass diese Straffung des Entwicklungsprozesses eine weitere Stufe (Alpha - Aurora) benötigt. Während im Trunk entwickelt wird, kann sich eine niedrige Version im Alphastadium, eine im Betastadium befinden und die Final in das Release gehen.

Um diese Builds zu präsentieren und breit zu testen, benötigt man entsprechende AUS- Channels für Updates. Zu den bisherigen (Nightly, Beta, Release) ist nun der reine Alpha-Channel - Aurora gekommen.

Das waren meine Worte!
Ich hoffe, dass diese nicht verwirren. Sehr gut nachlesbar - [1]. Und die Abb. aus dieser Quelle verdeutlicht es nach meiner Ansicht sehr gut [2].

[1] http://mozilla.github.com/process-releas…ment_specifics/
[2] http://mozilla.github.com/process-releas…ew_versions.png

Zitat von ChrisFOX

- okay hab es verstanden,

Ich bin nicht gern ein Schreiber von ellenlangen Beiträgen. Aber die obige Erklärung ist aus meiner Sicht noch komprimiert .
Vereinfacht soll eine Entwicklung - wie bis bisher aus - zwar auch nacheinander folgen (Nightly » Alpha » Beta » Release), aber eben nicht mehr auf einem Zeitstrahl.

Verstanden.
Dieses Modell ist gut und logisch. Zumindest in der Theorie!
Aber für mich persönlich gibt es noch jede Menge unbeantworteter Fragen, welche sich aus der Historie, aus dem praktischen Ablauf und dem Aufwand der entwicklungstechnischen Umsetzung ergeben!

Beispiele nur in Stichworten - Gecko und Tb, Altversionen und deren Sicherheitsupdates, Sicherheitsupdates noch im Push-Turnus von 5-6 Wochen, geänderte Bedeutung von MU-AUS, Bugzilla ....

Die Umsetzung bedeutet höherer Aufwand und sehr viel Disziplin. Sonst wäre es nur eine interessante *Nummern-* Spielerei!

... und folgerichtig müssen die Nightlies bei v6.0a1 ankommen ...
Und es wird wieder 64Bit- Win-Builds geben.

UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110412 Firefox/6.0a1 ID:20110412210314

Ab nun wird das Suffix *pre* [1] in der Build- Kennzeichnung (UA) nicht mehr auftauchen [2].

UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110413 Firefox/6.0a1 ID:20110413030543

http://hg.mozilla.org/mozilla-centra…ge=6bcaec19d09e

[1] http://www.pcwelt.de/forum/1225813-post48.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=649373

me,
allgemein bestätigt.

Jedoch habe ich hier 2 mit jeweils 1-ner Funktionseinschränkung. Bei beiden kann ich mir jedoch diese Funktionen auch händisch abrufen.