29 Reaktionen

Mozilla ändert Release-Zyklus von Firefox

Geschätzte Lesedauer:

Mehr als vier Jahre nach Einführung des Rapid-Release-Modells führt Mozilla eine Anpassung des Release-Zyklus von Firefox durch und ersetzt den bisherigen 6-Wochen-Zyklus durch einen variableren Zyklus.

Seit der Einführung des Rapid-Release-Modells, welcher Firefox nun schon mehrere Jahre begleitet, wird alle sechs Wochen ein neues Feature-Update von Firefox veröffentlicht, einzelne Verschiebungen ausgenommen. Nun hat Mozilla neue Release-Termine für 2016 bekannt gegeben, welche einen variableren Zyklus zeigen. Demnach werden neue Firefox-Versionen nicht mehr fix alle sechs Wochen veröffentlicht, sondern alle sechs bis acht Wochen. Außerdem wird im Dezember anstelle eines Feature-Updates lediglich ein Bugfix-Release mit Änderung der Versionsnummer an dritter Stelle erscheinen.

Die neuen Release-Termine Firefox 2016

8. März 2016 / 6 Wochen nach Firefox 44
Firefox 45, Firefox ESR 45

19. April 2016 / 6 Wochen nach Firefox 45
Firefox 46

Update 06.04.2016
Firefox 46 wurde auf den 26. April 2016 verschoben.

7. Juni 2016 / 7 Wochen nach Firefox 46 (6 Wochen durch Verschiebung von Firefox 46)
Firefox 47

2. August 2016 / 8 Wochen nach Firefox 47
Firefox 48

13. September 2016 / 6 Wochen nach Firefox 48
Firefox 49

Update 08.09.2016
Firefox 49 wurde auf den 20. September 2016 verschoben.

8. November 2016 / 8 Wochen nach Firefox 49 (7 Wochen durch Verschiebung von Firefox 49)
Firefox 50

13. Dezember 2016 / 6 Wochen nach Firefox 50, nur Bugfixes
Firefox 50.0.1

24. Januar 2017 / 6 Wochen nach Firefox 50.0.1
Firefox 51

Unabhängige Berichterstattung unterstützen.

Unterstütze wirklich unabhängige und Fakten-basierte Berichterstattung zu Mozilla, welche nicht das Ziel hat, Schlagzeilen zu produzieren, sondern objektiv zu informieren.

Dieser Artikel wurde von Sören Hentzschel verfasst.

Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, firefoxosdevices.org sowie sozone.de.

24 Kommentare - bis jetzt!

Eigenen Kommentar verfassen
  1. Chrono Meridian
    schrieb am :

    Der Zyklus sieht, ich sag mal, ungezwungener aus. 🙂
    Bestimmt aber wird es für viele immer noch viele Wochen zu kurz sein. ;p

  2. Sven
    schrieb am :

    Ein Releasezyklus wie bei Mesa3D wäre schön :p

  3. foobar
    schrieb am :

    Ich habe nichts gegen schnelle Releases, auch damals bei Einführung schon nicht. Aber ich habe auch damals schon gesagt, dass auf Dauer eine starrer Plan einfach nicht gut gehen wird.

    Man sollte einfach nicht nach Datum veröffentlichen. Sondern sich kleine(!) Feature-Ziele setzen und veröffentlichen sobald diese implementiert sind. „It’s done when it’s done“ in kleinen Häppchen. Dann dauert es halt mal 4, mal 8 Wochen. Who cares?

  4. schrieb am :

    Ist es nicht bald sinnvoller, die Zählweise der Versionsnummern etwas abzuändern? Ubuntu hat bspw. mit YY.MM ein ziemlich logisches System gefunden. Danach würde Firefox 51 lediglich Firefox 17.01 oder 2017.01 (um dem Millenium-Bug vorzubeugen) heißen. Spätestens bei Firefox 100 in 7 Jahren müssten die meisten den Überblick verlieren. 😉

  5. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    @Sven:

    Ein Releasezyklus wie bei Mesa3D wäre schön :p

    Also alle drei Monate und dazwischen viele kleine Updates?

  6. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Ich habe nichts gegen schnelle Releases, auch damals bei Einführung schon nicht. Aber ich habe auch damals schon gesagt, dass auf Dauer eine starrer Plan einfach nicht gut gehen wird.

    Das hat sich bis heute aber nicht bewahrheitet, dass es nicht gut gehen würde, der Release-Zyklus ging und geht wunderbar. Es wird nun lediglich mehr Flexibilität hinein gebracht, aber der Zyklus bleibt weitestgehend gleich. Dass es jetzt mal eine oder zwei Wochen mehr gibt, ist ja keine grundlegende Änderung, die alles verändert. Ein starrer Plan wie vorher ist sicher nicht optimal, nur "nicht gut gehen" klingt, als hätte es ernsthafte Probleme gegeben. 😉

    Man sollte einfach nicht nach Datum veröffentlichen. Sondern sich kleine(!) Feature-Ziele setzen und veröffentlichen sobald diese implementiert sind. „It’s done when it’s done“ in kleinen Häppchen. Dann dauert es halt mal 4, mal 8 Wochen. Who cares?

    Nein, dieses Modell gab es früher und war wirklich nicht gut. „It’s done when it’s done“ gilt so oder so, auch in diesem Modell. Es gibt kein Feature, welches unbedingt in eine bestimmte Version muss. Jedes Feature kommt dann, wenn es fertig ist. Dieses Release-Modell hat noch nie verschuldet, dass ein Feature halb fertig ausgeliefert wird. Mozilla kann wunderbar kontrollieren, dass Features hinter Einstellungen entwickelt werden und/oder nur in bestimmten Release-Kanälen an die Nutzer ausgeliefert werden.

    Dein Vorschlag, es so wie früher zu machen, trägt nur dazu bei, dass die Termine vollkommen unvorhersehbar sind, und das wäre überhaupt nicht gut, das schafft ganz eigene Probleme, die mit diesem Modell vermeidbar sind.

  7. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Ist es nicht bald sinnvoller, die Zählweise der Versionsnummern etwas abzuändern? Ubuntu hat bspw. mit YY.MM ein ziemlich logisches System gefunden. Danach würde Firefox 51 lediglich Firefox 17.01 oder 2017.01 (um dem Millenium-Bug vorzubeugen) heißen. Spätestens bei Firefox 100 in 7 Jahren müssten die meisten den Überblick verlieren.

    Das ist nicht sinnvoller, weil das derzeitige Versionierungssystem einen klaren Sinn hat. Änderung an erster Versionsstelle = Major-Release, Änderung an zweiter Versionsstelle = ESR-Update, Änderung an dritter Versionsstelle = Bugfixes und Sicherheitsupdates. Von diesem Aspekt her ist die Versionierung von Ubuntu – für Firefox – überhaupt nicht gut, denn das lässt sich damit so nicht abbilden. Für Ubuntu mag das passen, ich sag nicht, dass das generell schlecht sei. Aber die Anforderungen sind einfach andere bei Ubuntu und bei Firefox.

    Ich wüsste jetzt nicht, wieso man spätestens bei Firefox 100 den Überblick verlieren müsste. Im Prinzip gibt es doch nichts Übersichtlicheres als ein klares Nummernsystem, welches immer um eins inkrementiert wird. Das ist die einfachste Form der Versionierung und das System, welches man von so ziemlich jedem Produkt kennt. Es sind Ausnahmen, die es anders machen.

    Und letztlich ist es ja vollkommen egal, wie eine Version heißt, es ändert nichts am Produkt. Daher ist alles prima, wenn mit der Versionierung das ausgesagt werden kann, was ausgesagt werden soll. 😉

  8. Michael M.
    schrieb am :

    MediaWiki (die Software mit der Wikipedia betrieben wird) ist ein Beispiel dafür, dass man sogar mit noch kürzeren Release-Zyklen produktiv arbeiten kann, die MediaWiki-Version, die für Wikipedia verwendet wird, wird (von ein paar Ausnahmen abgesehen) nach einem festen Plan jede Woche aktualisiert.

    Das Ubuntu-Versionsschema ließe sich durchaus auch für Firefox sinnvoll einsetzen, eben als Ersatz für die erste Versionsstelle. während die weiteren Stellen weiterhin so behandelt würden, wie sie jetzt verwendet werden.

    Ich wüsste jetzt nicht, wieso man spätestens bei Firefox 100 den Überblick verlieren müsste.

    Zumindest ist es ziemlich wahrscheinlich, dass zu dem Zeitpunkt ein paar Seiten, die den Useragent-String auswerten, damit auf die Nase fallen. (Wobei man sagen muss: Wer das überhaupt tut, ist schon selber schuld.) Bei Opera hat man nicht ohne Grund ab der Version 10 die Versionsnummer etwas versteckt und sich weiterhin für Version 9.80 ausgegeben.

  9. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Zumindest ist es ziemlich wahrscheinlich, dass zu dem Zeitpunkt ein paar Seiten, die den Useragent-String auswerten, damit auf die Nase fallen.

    Das lässt sich natürlich in der Tat nicht ausschließen. Es gibt in der weiten Internet-Welt wirklich furchtbare Implementierungen von User-Agent-Sniffing. 🙁

  10. Stefan M.
    schrieb am :

    Ich finde eine Versionsnummer aus Jahr.Monat am Besten. Da weiß man als Kunde viel besser wie aktuell die Version ist.

    Vor allem bei regelmäßigen und automatischen Updates sind Versionsnummern für den Kunden/Konsumenten doch vollkommen egal. Da will man höchstens mal schauen ob die Version neu ist und das geht am Einfachsten über das Datum.

  11. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Um zu sehen, ob die Version aktuell ist, ist die Versionsnummer ja egal. Man ruft den Infodialog auf und dann wird automatisch überprüft, ob es eine neue Version gibt. Und wie gesagt ist Jahr und Monat nicht ausreichend. Du musst sowohl Bugfix- als auch ESR-Releases darstellen, du bräuchtest also wenigstens vier Stellen. Und ich bezweifle, dass die Mehrheit wüsste, was diese Versionsnummer darstellen sollen. Ein Datum lässt sich so nicht mehr ablesen, wenn man es nicht weiß, dass es ein Datum sein soll. Und Nummern, die immer um 1 erhöht werden, sind ein Schema, welches jeder Nutzer kennt und einfach vertraut ist. Klassischer geht es nicht. Das hat sich nicht grundlos durchgesetzt.

  12. schrieb am :

    Ich finde eine Versionsnummer aus Jahr.Monat am Besten. Da weiß man als Kunde viel besser wie aktuell die Version ist.

    Vor allem bei regelmäßigen und automatischen Updates sind Versionsnummern für den Kunden/Konsumenten doch vollkommen egal. Da will man höchstens mal schauen ob die Version neu ist und das geht am Einfachsten über das Datum.

    Dem kann ich zustimmen. Aus Endnutzersicht ist es, wenn man sich über eine Version informieren möchte, schöner und eleganter, wenn man erkennt, aus welchem Jahr das Release stammt.

    Aus Entwicklersicht wird meinen Informationen nach doch eh mit Mercurial gearbeitet, Versionen kann man da mit Tags markieren.

  13. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Dem kann ich zustimmen. Aus Endnutzersicht ist es, wenn man sich über eine Version informieren möchte, schöner und eleganter, wenn man erkennt, aus welchem Jahr das Release stammt.

    Siehe Antwort auf diesen Kommentar, Jahr plus Monat kann nicht ausreichend sein.

    Aus Entwicklersicht wird meinen Informationen nach doch eh mit Mercurial gearbeitet, Versionen kann man da mit Tags markieren.

    Versionsnummern werden nicht nur intern verwendet, sondern auch für sämtliche Kommunikation nach außen.

  14. Gonzo
    schrieb am :

    Ich fand die 6 Wochen Zyklen super, kann aber auch ganz gut mit max. 8 Wochen leben. Solange es nicht so lange dauert wie früher ist alles bestens.

  15. foobar
    schrieb am :

    Ob eine, zwei, drei oder vier Stellen ist vollkommen egal. Das, was bei einem Programm im „Über“-Dialog steht, ist lediglich eine Darstellung(!) einer Zahl.

    Das Textsatzsystem TeX hat als Versionsummer eine Näherung der Zahl Pi. Mit jedem neuen Release nähert man sich etwas näher an. Momentan ist man bei „3.14159265“. Das ist EINE Zahl (ein Float), die hochgezählt wird.

    Man kann auch bei x.y.z die Punkte einfach weglassen und entweder +1, + 10 oder +100 machen.

    Die Datumsvariante „2015.10“ kann man in einen Timestamp umrechnen.

    JEDE Versionsummer lässt sich auf EINE Zahl zurückführen und diese Darstellung quais beliebig in jede andere Darstellung transformieren. Die Bits des Timestamp könnte man beispielsweise in gleichgroße Blöcke aufteilen und Punkte dazwischen machen. Dann hätte man auch irgendwas wie Version „30.44.23“. (Randnotiz: genauso funktionieren IPv4-Addressen, das sind auch einfach nur 32 Bit, die nur der schöneren Darstellung/Lesbarkeit wegen in kleine Blöcke geteilt werden).

    Genauso kann ich eine Liste definieren 1=Monsun, 2=Sören, 3=Foobar, 4=Automat, … und bei jedem neuen Release (egal ob „Bugfix“ oder „Major“) das entsprechende Wort nehmen. Die Zahl könne ich aber genausogut in ihre Bits zerlegen udn ein 0.0.1 oder 0.3 oder 3.0 draus machen, jenachdem wo ich die Punkte hinsetze.

  16. Markus
    schrieb am :

    Dieses Versionsrennen finde ich nicht wirklich übersichtlich, eher Chaotisch.
    Zwei bis drei Versionen pro Jahr sollten doch eigentlich reichen, immer dann vielleicht, wenn eine grundlegende, bedeutende technische Änderung oder ein bedeutendes Feature hinzugekommen ist. Meilensteine eben. Kleine Features sollten eher Bugfixes sollten eher nach den Punkt kommen (oder Bugfixreleases generell mit Buchstaben wie z.B. 48.2.a?). 
    Ich finde dieses sture hochzählen eher chaotisch bis unbeholfen.
     

  17. Manu
    schrieb am :

    Um mal wieder zum eigentlichen Thema, dem Release-Zyklus von Firefox, zurückzukommen:

    Was exakt war denn nun ein Nachteil des vorhersehbaren 6-Wochen-Rhythmus?

    Was ist besser an „6 6 7 8 6 8 6 6“ Wochen?

    Das sind im Durchschnitt nun 46 Tage anstatt wie bisher 42 Tage. Wozu diese minimalen Variationen?

    Müssen sich die Nutzer nun nach den Urlaubszeiten der Mozilla-Angestellten richten?!
    Oder wie kommt diese holprige Zahlenfolge zustande?
    Ich kann leider keinerlei Regel darin erkennen. Bitte, klärt mich auf!

  18. Marcel
    schrieb am :

    Ich wette mal dass Version 48 oder 50 e10s für alle eingeschaltet werden wird. Die 8-wöchige Betaphase würde zumindest etwas mehr Zeit zum testen geben. Zumindest gehe ich davon aus dass es schon Pläne gibt.

    Vorallem die letzten beiden Releases sind sehr interessant. Sollte es sich bei 50.0.1 um ein Bugfix Release handeln hat v51 sogar 12 Wochen Entwicklungszeit. Wurde schon angekündigt ob da irgendetwas "besonderes" released wird?

  19. Marvin
    schrieb am :

    Naja was die Versionsnummer betrifft: Ich hab keinen Dunst welche Version aktuell ist, nach Firefox 17 hab ich aufgehört zu zählen.. Womöglich könnte man sich die Versionsnummern einfach schenken, denn wie du bereits sagtest, man kann es nicht an der Softwareweiterentwicklung festmachen wie der Versionszähler inkrementiert wird. Momentan sind es ja einfach nur die Anzahl der 6 Wochenzyklen die seit mitte/ende 2010 vergangen sind ^^

  20. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    @foobar:

    Ob eine, zwei, drei oder vier Stellen ist vollkommen egal. Das, was bei einem Programm im „Über“-Dialog steht, ist lediglich eine Darstellung(!) einer Zahl.

    Das Textsatzsystem TeX hat als Versionsummer eine Näherung der Zahl Pi. Mit jedem neuen Release nähert man sich etwas näher an. Momentan ist man bei „3.14159265“. Das ist EINE Zahl (ein Float), die hochgezählt wird.

    Man kann auch bei x.y.z die Punkte einfach weglassen und entweder +1, + 10 oder +100 machen.

    Die Datumsvariante „2015.10“ kann man in einen Timestamp umrechnen.

    JEDE Versionsummer lässt sich auf EINE Zahl zurückführen und diese Darstellung quais beliebig in jede andere Darstellung transformieren. Die Bits des Timestamp könnte man beispielsweise in gleichgroße Blöcke aufteilen und Punkte dazwischen machen. Dann hätte man auch irgendwas wie Version „30.44.23“. (Randnotiz: genauso funktionieren IPv4-Addressen, das sind auch einfach nur 32 Bit, die nur der schöneren Darstellung/Lesbarkeit wegen in kleine Blöcke geteilt werden).

    Genauso kann ich eine Liste definieren 1=Monsun, 2=Sören, 3=Foobar, 4=Automat, … und bei jedem neuen Release (egal ob „Bugfix“ oder „Major“) das entsprechende Wort nehmen. Die Zahl könne ich aber genausogut in ihre Bits zerlegen udn ein 0.0.1 oder 0.3 oder 3.0 draus machen, jenachdem wo ich die Punkte hinsetze.

    Alles richtig. Aber bedenke, dass Versionsnummern auch dafür da sind, um über eine bestimmte Version kommunizieren zu können. Das ist leichte Verständlichkeit Trumpf. 😉

  21. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    @Markus:

    Dieses Versionsrennen finde ich nicht wirklich übersichtlich, eher Chaotisch.

    Ich finde dieses sture hochzählen eher chaotisch bis unbeholfen.

    Diese Folgerung ergibt ja nun nicht wirklich viel Sinn. Wie kann ein ganz klarer Plan auf dich chaotisch oder unbeholfen wirken, wo doch das Gegenteil offensichtlich ist? Erkläre das bitte.

    Zwei bis drei Versionen pro Jahr sollten doch eigentlich reichen

    Nein. Es bringen nicht sowohl Mozilla als auch Google so häufig neue Versionen heraus, weil nichts dafür sprechen würde, das Gegenteil ist auch hier zutreffend. Gerade, weil Google das macht, kann Mozilla es sich nicht leisten, nicht mitzuziehen. Außer, sie wollen noch mehr Nutzer verlieren, weil Firefox immer wieder an Boden verliert.

    immer dann vielleicht, wenn eine grundlegende, bedeutende technische Änderung oder ein bedeutendes Feature hinzugekommen ist. Meilensteine eben.

    Es gibt in ausnahmslos jedem Major-Release nennenswerte Neuerungen.

    Kleine Features sollten eher Bugfixes sollten eher nach den Punkt kommen (oder Bugfixreleases generell mit Buchstaben wie z.B. 48.2.a?). 
     

    Ein hinten angestelltes A in der Versionsnummer steht üblicherweise für eine Alpha-Version. Und wenn du Updates für kleinere Features willst, müsste es alle zwei Wochen neue Updates geben, nicht mehr nur zwei bis drei mal im Jahr, wie du es gerade noch wolltest. Damit widersprichst du deinem eigenen Standpunkt.

  22. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    @Manu:

    Um mal wieder zum eigentlichen Thema, dem Release-Zyklus von Firefox, zurückzukommen:

    Was exakt war denn nun ein Nachteil des vorhersehbaren 6-Wochen-Rhythmus?

    Was ist besser an „6 6 7 8 6 8 6 6“ Wochen?

    Das sind im Durchschnitt nun 46 Tage anstatt wie bisher 42 Tage. Wozu diese minimalen Variationen?

    Es geht nicht darum, dass die Anzahl der Wochen unterschiedlich ist, es geht um die konkreten Zeitpunkte, welche besser oder weniger gut geeignet sind. Aufgrund jahrelanger Erfahrungen weiß man beispielsweise, dass im Dezember Weihnachten und Neujahr ist, wie Mitarbeiter Urlaub haben, wann Workweeks geplant sind etc. Man reagiert ganz einfach flexibler auf die Realität.

    Müssen sich die Nutzer nun nach den Urlaubszeiten der Mozilla-Angestellten richten?!

    Selbstverständlich müssen sie das unter Umständen, ohne Mozilla-Angestellte gibt es schließlich keinen Firefox-Release. Ich verstehe die Frage nicht wirklich.

    Oder wie kommt diese holprige Zahlenfolge zustande?
    Ich kann leider keinerlei Regel darin erkennen. Bitte, klärt mich auf!

    Ganz einfach, weil es keine Regel dahinter gibt. Jeder Termin ist individuell ausgewählt.

  23. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    @Marcel:

    Ich wette mal dass Version 48 oder 50 e10s für alle eingeschaltet werden wird. Die 8-wöchige Betaphase würde zumindest etwas mehr Zeit zum testen geben. Zumindest gehe ich davon aus dass es schon Pläne gibt.

    Die Prognose Firefox 48-50 mag hinkommen, es gibt aber definitiv keine konkreten Pläne, weil sich das wirklich von Version zu Version entscheidet. Man weiß jetzt gerade mal erst, dass man e10s für Firefox 46 für Nutzer ohne Add-ons plant. Was dann mit Firefox 47 ist, wird davon abhängen, wie gut das funktioniert und was man in den weiteren sechs Wochen alles beheben konnte. Auf einen bestimmten Release hinarbeiten, das tut man vielleicht, aber es gibt jetzt keinen Plan, der schon sagt, dass e10s ab Firefox XY für alle Nutzer standardmäßig aktiviert sein soll.

    Vorallem die letzten beiden Releases sind sehr interessant. Sollte es sich bei 50.0.1 um ein Bugfix Release handeln hat v51 sogar 12 Wochen Entwicklungszeit. Wurde schon angekündigt ob da irgendetwas "besonderes" released wird?

    Ich denke nicht, dass es da irgendwas Besonderes geben wird. Wenn du die vielen Feiertage und Urlaube in dieser Phase berücksichtigst, und dass es im Dezember auch wieder eine Work Week geben wird, geht ja einiges an Zeit verloren. In dieser Zeit passiert jedes Jahr so wenig wie sonst nie. Zwölf Wochen zu dieser Zeit sind nicht so viel wie zwölf Wochen zu einer anderen Zeit. In dieser Phase des Jahres gab es in den letzten Jahren auch schon Verschiebungen, wo man von den sechs Wochen abgewichen ist, wenn auch nicht so stark, wie es jetzt geplant ist. 😉

  24. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    @Marvin:

    Naja was die Versionsnummer betrifft: Ich hab keinen Dunst welche Version aktuell ist, nach Firefox 17 hab ich aufgehört zu zählen.. Womöglich könnte man sich die Versionsnummern einfach schenken, denn wie du bereits sagtest, man kann es nicht an der Softwareweiterentwicklung festmachen wie der Versionszähler inkrementiert wird.

    So einfach ist das nicht, Versionsnummern sind auch für die Kommunikation wichtig. Es hat in jedem Fall Vorteile, wenn man Versionen konkret benennen kann.

    Momentan sind es ja einfach nur die Anzahl der 6 Wochenzyklen die seit mitte/ende 2010 vergangen sind ^^

    Nur annäherungsweise. Es gab in den vergangenen Jahren mehrere Verschiebungen.

Und jetzt du! Deine Meinung?

Erforderliche Felder sind mit einem Asterisk (*) gekennzeichnet. Die E-Mail-Adresse wird nicht veröffentlicht.
  1. Nach Absenden des Kommentar-Formulars erfolgt eine Verarbeitung der von Ihnen eingegebenen personenbezogenen Daten durch den datenschutzrechtlich Verantwortlichen zum Zweck der Bearbeitung Ihrer Anfrage auf Grundlage Ihrer durch das Absenden des Formulars erteilten Einwilligung.
    Weitere Informationen