Geliştirme aşaması (yazılım)

Yazılım teknolojisinde bir geliştirme aşaması , oluşturulacak bir yazılım ürününün belirli bir zamanda ulaştığı veya ulaşması gereken tamamlanma halidir. Proje yönetiminin bir parçası olarak ilgili aşamalar zaman ve içerik açısından belirlenir . Proje için seçilen süreç modeline , faaliyetlerine ve kilometre taşlarına veya üreticiye özgü yöntem konseptlerindeki ve geliştirme ortamlarındaki spesifikasyonlara dayanırlar .

Daha dar bir anlamda , geliştirme aşaması, çalıştırılabilir yazılımı ifade eder ; H. Test için bir projenin yayın yönetimi süreçlerinin bir parçası olarak veya kullanıcılarına sağlanan çalıştırılabilir programlar üzerinde . Proje durumuna bağlı olarak, genellikle daha küçük bakım projelerinde bazı aşamalar çıkarılır, birleştirilir veya yazılım yalnızca tek bir son sürüm olarak sunulur.

Daha geniş anlamda , yazılım için projenin tüm seyri boyunca farklı geliştirme aşamaları vardır, bu aşamalarda sonuçlar, belirli kilometre taşlarına ('geliştirme aşamaları') atanan kavramsal proje aşamalarında da ortaya çıkar. Örnek bkz. Her aşamanın sonunda, tanımlanan proje sonuçları sonraki işlem aşamalarına aktarılır.

Son yazılım durumuna ulaştıktan sonra, geliştirme döngüsü başlar i. d. Genellikle yeni bir yazılım sürümü amacıyla uygulamayı genişletmek için önlemler / projeler ile yenidir .

Amaç / farklılıklar

Amaç birkaç geliştirme aşamalarını tanımlamak için daha güvenilir sonraki faaliyetlerini işlemek edebilmek amacıyla proje süresince belirlenen vade seviyeleri ile sabit noktaları elde etmek genellikle. Genellikle farklı gelişim aşamaları z. B. önceki aşamada zaten test edilmiş olan işlevselliklere dayanan sonraki test seviyelerinde / test türlerinde işlevsel ayrıntıları kontrol edebilmek için yazılım testinde uygulanmıştır .

Bilgisayar programları için ayrı yazılım geliştirme aşamaları arasındaki farklılıklar , örneğin aşağıdakiler olabilir - örnek olarak verilen sürüm amacıyla kullanılmak üzere :

  • Bazı işlevler henüz uygulanmadı; bireysel işlevleri önceden test etmek için
  • ... veya yalnızca basit bir biçimde uygulanır (özel durumlar olmadan); ayrıca ilk / erken testler için.
  • Önceki aşamada, yazılım yalnızca belirli test türleri (alfa testleri gibi) kullanılarak kontrol ediliyordu; beta testleri yapmak.
  • Yazılım ayrıca yardımcı rutinleri de içerir (örn. Stub'lar veya sürücüler); alt programları test etmek için .
  • Uygulama, özel bir sisteme veya test ortamına aktarılmaya hazır hale getirilir ve gerekirse hedef sisteme uyarlanır; üretim testleri veya yük testleri yapmak.
  • Uygulama, hata durumlarının test edilmesini ve belgelendirilmesini destekleyen yardımcı rutinler içerir; genel test kullanıcıları için.
  • Aşamayla ilgili geçişler, uygulamanın tamamını veya yalnızca (sonraki) kurulum için ayrı bileşenleri içerir.
  • Uygulama tamamen işlevseldir (son aşama); üretim ortamına son devir için .

Gelişim aşamalarına örnekler

Hedeflenen olgunluk seviyeleri ve isimleri ile gelişim aşamalarının sayısı önemli ölçüde değişmektedir. Özellikle standart yazılım durumunda ( sistem yazılımı dahil ), üreticiler genellikle yazılımlarını aşamalı olarak nasıl geliştireceklerini, ilgili yazılım sürümlerini kimler için ve hangi amaçlarla sağladıklarını ve bu aşamaları nasıl adlandıracaklarını belirler. Geliştirilmesinde bireysel yazılım, geliştirme aşamalarında / yazılım sürümleri genellikle şirkete özel olarak yürütülmektedir; genellikle genellikle tanımlanmamış, daha çok projeye özel şartları izleyin.

Yazılım sürümleri için geliştirme aşamaları ve atamalar örneğin şunlar olabilir:

pre-alphaalphabetasürüm adayısürüm .

Diğer durumlarda, bir üretici aşağıdaki gibi sürüm tanımlarını uygular:

KAPALI → NİHAİ STABİL → NİHAİ → MEVCUT BİNA → PLANLANDI .

Yazılım geliştirmedeki bu tür ana aşamalar arasında, örneğin rapor edilen program hataları durumunda birkaç düzeltme denemesinden (ve test seviyesinden) gelen herhangi bir sayıda ara yazılım sürümü vardır .

Genel olarak yazılım geliştirme için i. H. sadece çalıştırılabilir programlar için geçerli değildir, örneğin aşağıdaki aşamalar i. S. kilometre taşlarından bilinir:

Proje tanımı , gereksinim analizi , şartname , fonksiyonel şartname , kod analizi , birim testi, sistem testi, proje kabulü

Çalıştırılabilir yazılım için yazılım aşamaları

Yazılım geliştirme aşamaları

Ön alfa sürümü

Genel olarak, ilk alfa sürümünden önceki herhangi bir geliştirme aşaması, bir ön alfa sürümü olarak adlandırılabilir ( Latince prae- 'erken' ve Yunan alfabesi alfanın ilk harfinden , ayrıca 1 için α ' karakteri olarak) . Böyle bir sürüm genellikle yazılımın yarı yarıya tamamlanmış bir modülü sunulacağı zaman kullanılır. Diğer bir isim, geliştirici önizlemesidir ( İngilizce önizleme geliştiricisinin , aynı zamanda sıklıkla DP olarak kısaltılmıştır ).

Alfa versiyonu

Bir bilgisayar programının yabancılar tarafından test edilecek ilk sürümüne (gerçek geliştiriciler değil) genellikle alfa sürümü denir . Terim tam olarak tanımlanmasa da, bir alfa sürümü genellikle yazılım ürününün temel bileşenlerini içerir - ancak sonraki sürümlerde işlev yelpazesinin genişletilmesi neredeyse önemlidir.

Özellikle, alfa sürümleri genellikle üretken kullanım için uygun olmayan büyüklükte veya miktarda program hataları içerir .

Ayrıca geliştirici önizlemeleri, İngilizce Geliştirici önizlemeleri veya geliştirici sürümleri gibi alfa sürümleri de mevcuttur. Bu genellikle üçüncü taraf geliştiriciler için özel bir çevrede gerçekleşir .

Beta sürümü

Beta sürümleri , özellikle Web 2.0 hizmetleri için genellikle basit logolarla tanımlanır.

Beta sürümü, üretici tarafından test amacıyla yayınlanan bir bilgisayar programının ilk sürümüdür . Bu terim tam olarak tanımlanmamıştır, bir beta sürümünü diğer sürümlerden ayırmak için pratik bir kural olarak, genellikle programın tüm temel işlevlerinin içinde uygulandığı, ancak henüz tam olarak test edilmediği durumdur. Program, verimli kullanımı tavsiye edilmeyen birçok, muhtemelen ciddi hatalar içerebilir veya içerecektir.

Özellikle beta testinin faydaları , son sürümden önce bile ( diğer programlarla çakışmalar, yalnızca uygulamada belirli sorunlar, donanım bileşenleri , belirsiz uygulanan gereksinimler veya kullanıcı arayüzündeki belirsizlikler gibi) tipik olarak meydana gelen hataların ( İngilizce sürüm) olmasıdır. ) programın tanınması ve düzeltilmesi veya en azından belgelenmesi.

Bir beta test kullanıcısı genellikle ilk bağımsız veya anonim üçüncü taraf testçisi ve kullanıcısı olarak adlandırılır.

Programların beta sürümleri genellikle 0 ile ana sürüm numarası olarak tanınabilir - elbette, bu varyant yalnızca ilk bitmiş sürümden (1.0) önceki beta sürümleri için geçerlidir - veya beta soneki .

Beta sürümleri genellikle sürüm adayları veya bitmiş sürümlerle aynı şekilde dağıtılmaz . Aşağıdaki seçenekler kullanılır:

  • Tanımlanan anlık görüntüler (mevcut geliştirme durumları), kaynak kodu yönetim sisteminden düzenli aralıklarla (olmayan) üretilir ve kaynak kodunda veya önceden derlenmiş bir paket olarak en bloc olarak sunulur . Bu, günlük ( gece oluşturma ), haftalık olarak veya geliştiricilerin uygun gördüğü herhangi bir zamanda (örneğin bir alt sistemin tamamlanmasından sonra) yapılabilir. Böyle bir sürüm, beta testçilerinin hataları geliştiricilere raporlamasını kolaylaştırmak için otomatik bir hata izleme modülü ( bkz.Amarok ) içerebilir . Bu genellikle, tanımlanmış geliştirme hedefleri ve sabit bir yayın programı olan (örneğin GNOME ile ) büyük projeler için bir normdur .
  • Beta sürümü, kaynak kontrol sistemindedir ve bir gün sağlanmış (bir işaret), ancak başka şekilde ayrı olarak ele alınmaz. Bağımsız sağlayıcılar daha sonra bu geliştirme düzeyini önceden derlenmiş paketlerinin temeli olarak kullanabilir . Bu, çok hızlı değişen ve hiç veya nadiren sabit sürümlerle çalışabilen, ancak mevcut sürümlere (örneğin Dirac , Xine ) genel ilgi olan projeler için kullanılır .
  • Sabit bir beta sürümü yoktur, beta şu anki HEAD'dir , yani sürekli değişen, gerçek geliştirme durumu. Beta test ediciler mevcut durumu kaynak kod yönetim sisteminden indirmeli, yapılandırmalı ve derlemelidir; bu aktivite normalde proje tarafından sağlanan komut dosyaları tarafından otomatik olarak gerçekleştirilir. Bu en yaygın olanıdır, ancak önceki iki yöntemden biriyle de birleştirilebilir (kural budur).

Sürekli beta

İnternetin sürekli gelişimi ile ilgili olarak, web siteleri ve yazılımların da sürekli olarak geliştiğini ve bu nedenle hiçbir zaman gerçekten bitmediğini açıklayan bir terim. Böylece kalıcı bir gelişme durumu, "Perpetual Beta" meydana geldi. " Sürekli Entegrasyon " un aşırı programlama konseptini hesaba katan Web 2.0 konsepti içinde bir slogan olarak ortaya çıktı .

Sürüm Adayı / Ön Sürüm

Kullanımıyla ilgili uyarılar içeren bir yayın öncesi ekran görüntüsü

Bir sürüm adayı (kısaca RC , sürüm adayı için İngilizce'den ), bazen ön sürüm olarak da anılır (İngilizceden " yayın öncesi " veya "ön sürüm sürümü"), yazılımın son test sürümüdür. Yazılımın son sürümünün içermesi gereken tüm işlevler zaten mevcut (sözde özellik tamamlandı ) ve bilinen tüm hatalar düzeltildi. Son sürüm, nihai bir ürün testi veya sistem testi gerçekleştirmek için yayınlamadan önce sürüm adayından oluşturulur . Yazılımın kalitesi kontrol edilir ve kalan program hataları aranır.

Küçük bir değişiklik bile yapılırsa, başka bir sürüm adayı oluşturulmalı ve testler tekrarlanmalıdır. Bu nedenle sürüm adayları genellikle numaralandırılır (RC1, RC2, vb.). Başka bir değişiklik yapılmaz ve bir sürüm adayını nihayet gerekli kalite standartlarında tutar, bu nedenle son ek RCx kaldırılır ve böylece sürüm ve sürüm (ayrıca İngilizce son sürüm , son sürüm veya son sürüm , son sürüm) açıklanır ve yayınlanır.

Beta sürümlerinden önemli ölçüde daha kararlı olan ancak henüz bir sürüm adayı olarak test edilmeyen sürümler , bazı geliştirme projelerinde gama sürümleri olarak adlandırılır .

İçin aygıt sürücüleri için , Windows , bazen statü vardır WHQL Aday (tercüme WHQL-aday ). Bu, RC'ye karşılık gelen ve üreticinin WHQL testi için sunduğu bir sürücü sürümüdür, ancak ilgili sertifika henüz gerçekleşmemiştir.

Serbest bırakmak

Yazılımın bitmiş ve yayınlanmış sürümü, sürüm , bazen de ana sürüm olarak bilinir . Bu, geleneksel olarak sürüm numarasındaki artışla el ele gider . Medyaya dayalı dağıtım durumunda, bu sürüm, CD-ROM'lar veya DVD'ler gibi veri taşıyıcılara kopyalandığı, yani gerçekten somut bir ürün olarak üretilen, üretim için baskı atölyesine teslim edilir .

Bu statü için çeşitli isimler de belirlenmiştir:

Üretime / Web'e (RTM / RTW), ayrıca İlk Müşteri Sevkiyatına (FCS) Yayın
İnternette yeniden üretime ve yayına hazır ( web )
Kararlı
artık değişmeyen kararlı bir sürüm için
Final
son (son) versiyon için
Genel Kullanılabilirlik (GA)
genel kullanılabilirlik anlamına gelir. Terim, sürümün pratik kullanım için yayınlandığını ve dağıtıldığını veya çeşitli ortamlarda mevcut olduğunu açıkça ortaya koymaktadır.
Altın , ayrıca Altın Usta (GM)
Goldmaster, nihayet basın mağazasına giden ve (fiziksel olarak) kopyalanan versiyondur. Altın Ustayı elde etmek için tüm hataların giderilmesi ve son ürünün tamamen tamamlanıp son saklama ortamına (Goldmaster DVD) yazılması gerekir. İsim müzik endüstrisinden geliyor. Goldmaster DVD'si baskı dükkanına gönderilmeden kısa bir süre önce en sonunda üretilir. Daha önce herhangi bir güncelleme veya benzeri olmadığından, birkaç Altın Usta oluşturuldu ve son sürüm basın mağazasına gönderilmeden önce kapsamlı bir şekilde test edildi. Gold Master, matbaaya orijinal olarak gelen ve daha sonra kopyaları yapılan son satış sürümüdür. Müzik ve film endüstrisinde, Golden Master hala yaygın olarak kullanılmaktadır (CD ve DVD üretimi), yazılım endüstrisinde büyük ölçüde güncellemelerle değiştirilmiştir. Goldmaster DVD'sinde genellikle yalnızca bir parça vardır.

Tanımlamalar

Yazılım sürümlerinin tanımları, sürümleri genellikle standart değildir ve genellikle projeden projeye değişir. Bazı üreticiler ayrıca bir tür yol haritasında yayınlanan (planlanan) geliştirme durumları için amaçlanan tanımlamaları belirtir . "Sürüm" veya "Sürüm" yerine, Aşağıdaki terimler, yayınlanmış yazılımlar için yaygındır:

İnşa etmek
Sonucu derleme kaynak kodu . In inşa süreci , otomatik olarak yönetilir yapı numarası olduğu genellikle tüm kaynak kodu derlenir, özellikle bir artırılır. Yazılım genellikle test için dahili olarak derlenmiş zorundadır Ancak, böyle bir yapı genellikle önceki ile aynı sürüm numarasına sahip yapı . Ancak, daha önce yayınlanan sürümler veya sürümler için bile, özellik güncellemeleri veya hata düzeltmeleri gibi, güncelleme yayınlandıkça daha yeni derlemeler gibi genellikle bakım içindir .
Bazı programlar, yapı numarasını sürüme bir tire ile ekler , ör. B. 1.2.3-4567, burada 1 ana sürüm numarası, 2.3 alt sürüm ve revizyon numarası ve 4567 (kısa çizgiden sonra) yapı numarasıdır. Ayrıca sürüm numarasına bakın .
versiyon
Benzersiz bir sürüm numarası verilen bir yapı , bir projenin yeni bir sürümü olarak kabul edilir. Sırasında mı düzeltmeleri veya hata düzeltmeleri z. Örneğin, bir bakım sürümü yayınlanırsa, aynı sürüm numarasına sahip olabilir, ancak daha yüksek bir yapı numarasına veya adın " Hizmet Sürümü  1" veya sadece " Bakım Sürümü " gibi bir ekine sahip olabilir .
Serbest bırakmak
Genel olarak, yayımlanmış bir versiyonu olarak adlandırılır serbest bırakılması . Yayınlanmamaktadır İç versiyonları normalde bu nedenle olmayan bırakma olarak adlandırılan, ancak bu tür versiyonları veya durabilir sızıntı s ve dolayısıyla da halka ulaşmak.

Beta sürümü terimi de, açıkça tanımlanmadığı için sorunludur ve bu nedenle temelde herhangi bir bitmemiş geliştirme durumunu temsil edebilir. Dolayısıyla, bir yandan tüm proje ile ilgili geliştirme aşamalarından sonra aynı atama vardır, diğer yandan, atama yalnızca son eklenen kısmi bileşenlere atıfta bulunabilir (ve projenin geri kalanı aslında kararlıdır ve beta sürümü değil).

Yayınlanan yazılımın kendisi genellikle farklı adlara sahiptir. Sözde ek olarak “serbest bırakılması”, orada da “nihai” veya son hali (: bitmiş sürümü veya ayrıca son hali Almanca). Bununla birlikte, "kararlı" terimi de vardır , yani genellikle kararlı bir sürüm olarak kararlıdır . Burada da, farklı isimler oldukça yaygın olduğu açıktır: yerine versiyonunun, bir yayın da ad verebilirsiniz: a nihai sürüm bir geliştirme projesi yalnızca yayınlanmış olan son hali .

Bitmemiş versiyonlar için durum farklı değildir. İster pre-alfa , alfa ya da beta versiyonu : En yaygın olan , “deneme” , “kararsız” (kararsız), “test” de olduğu gibi “ön izleme” bir şekilde her biri isteğe göre, yine “versiyonu” veya olarak “serbest”” , Ama aynı zamanda bir "yapı" olarak . Bir yapı en belirsiz olanıdır, ancak aynı zamanda bitmemiş bir yazılımın durumunu göstermek için yayınlarda sıklıkla kullanılır. Ancak, kararlı ve bitmiş sürümlerin genellikle bir yapı numarası vardır.

Özel bir özellik, gecelik yapı olarak çevrilen adlandırmadır : gecelik yapı . Bu ada sahip bir program, tamamen kararlıdan tamamen çalışamaz duruma kadar herhangi bir şey olabilir, çünkü işlem neredeyse her zaman geceleri otomatik olarak çalışır (dolayısıyla adı) ve geliştiricilerin gün boyunca değişikliklerini yaptıkları kaynak kodun mevcut sürümüne dayanır. . Kaynak kodu son değişikliklerden ( ingilizce bozuk ) zarar görmüş olabilir, ancak derleyici için tercüme edilmeye devam eder, ancak derleme sürecini başarıyla çalıştırırken program yine de çalışamaz. Bu nedenle, gecelik yapı olarak adlandırılması , yazılım projesinin geliştirme aşaması hakkında hiçbir şey söylemez .

Bununla birlikte, bir yazılım projesinin geliştirme düzeyine bakılmaksızın belirli bir hedef kitleye yönelik terimler de yaygındır. Bunlar çoğunlukla geliştirici için avantajlı olan hedefin, belirli koşullar altında harici bir beta testi yapma amacını güder . Daha geniş kapsamlı "beta programları" için kullanılan terimler de standartlaştırılmamıştır ve projeden projeye farklıdır, ancak ortak anahtar kelimeler vardır:

Dahili yapı veya özel yapı
yalnızca dahili olarak test edilen bir projenin yürütülebilir bir sürümünü ifade eder.
Geliştirici Derlemesi
özel olarak (harici geliştiriciler için İngilizce geliştirici ) amaçlanan bir deneme sürümüdür . Bu, çoğunlukla projenin çalışması için birçok üçüncü taraf sağlayıcı gerekli olduğunda kullanılır , örn. B. diğer üreticilerin birçok programının çalışabileceği (veya uyumlu kalması veya olması gereken) bir işletim sisteminde .
Örnek: Rhapsody Developer Release veya Mac OS X Developer Preview
Kapalı Beta
özel bir çevrenin kullanımına sunulan bir beta sürümünü belirtir .
Örnek: Insider Programı olarak adlandırılan Microsoft tarafından açık (yalnızca kaydedilebilir) bir programın katılımcıları için yayınlanan Insider Build veya Insider Preview olarak Windows 10 . Test uzmanlarının kabulü zamanla sınırlıydı.
Herkese açık beta
açıkça ve kayıtsız bir şekilde erken benimseyenler için tasarlanmış bir beta sürümünü ifade eder . Örnek: Mac OS X Public Beta , Mac OS X 10.0'ın beta sürümü .
Erken erişim
erken testlere ve / veya geliştirici sürümlerine genellikle ücretli erişim ( İngilizce erişim teklifleri) sunan bir istemci programını ifade eder . Bu, özellikle bilgisayar oyunlarında popülerdir , çünkü bir yandan oyuncuların oyun dünyasının belirli unsurlarını bir başlık yayınlanmadan çok önce araştırmasına izin verir ve çeşitli donanımlarda kararlılık testlerine yardımcı olur ve diğer yandan geliştiricilerin değişiklik yapmasına olanak tanır. oyuncuya dayalı geri bildirime göre erken bir aşamada . Geliştirme stüdyosu erken erişim satışları yoluyla oyunu geliştirmek için önceden para aldığından , erken erişim programları da genellikle iyi bir finansman kaynağıdır .

Başka bir adlandırma türü, belirli bir sürümün yayınlanma nedeninin veya amacının belirlenmesidir. "Bakım Sürümü" ve "Servis Sürümü" , yani bakım amaçlı bir sürüm esas olarak burada kullanılır . Bu genellikle bakım versiyonu olarak çevrilir.

Yayın sonrası hata düzeltmesi

Yazılım üreticileri, daha önce yayımlanmış olan yazılımdaki hataları düzeltmek için güncellemeler, düzeltmeler , yamalar ve hizmet paketleri yayınlar . Pek çok modern uygulama ve işletim sistemiyle , bunlar daha sonra İnternet üzerinden manuel veya otomatik olarak elde edilebilir .

Örnek olarak Firefox

Web tarayıcısı Mozilla Firefox , her altı haftada bir dört farklı sürümde görüntülenir: deneysel sürüm Firefox Nightly (ön alfa), deneysel sürüm "Firefox Developer Edition", çoğunlukla kararlı sürüm Firefox Beta ve kararlı sürüm Firefox , her biri kendi Differentiate'de. sürüm numarası, örneğin B. Firefox Aurora 11, Firefox Beta 10, Firefox 9. Ayrıca "gece" Nightly Build'ı da indirebilirsiniz (mevcut geliştirme durumu, yalnızca test için uygundur). Bu şekilde, bir yandan geliştirme süreci hızlandırılabilirken, diğer yandan Beta veya Aurora sürümleri kullanılarak, kullanıcılar kararlı sürümün gelecekteki işlevlerini test etmeye ve değerlendirmeye yardımcı olabilir ve bir anda hataları ve güvenlik açıklarını belirleyebilir. Erken aşama, Aurora sürüm on iki ve Beta sürümü son kararlı sürümden altı hafta önce halka açıklanacağından beri.

Ayrıca bakınız

Edebiyat

  • Manfred Precht, Nikolaus Meier, Dieter Tremel: Temel BT bilgisi. Pearson Education, Münih 2004, ISBN 3-8273-2129-8 .
  • Mike Gunderloy: Kodlayıcıdan Geliştiriciye. Wiley_Default, 2004, ISBN 0-7821-4327-X .

Bireysel kanıt

  1. Ralf Ötinger Kullanıcı dostu yazılım geliştirme [1] Aşamalar: problem analizi, gereksinim tanımı
  2. ES2000 için yapılan yazılım Arşivlenen kopya ( bir hatıra orijinal Aralık 11, 2017 dan Internet Archive ) Bilgi: arşiv bağlantısı otomatik olarak takılmış ve henüz kontrol edilmedi. Lütfen orijinal ve arşiv bağlantısını talimatlara göre kontrol edin ve ardından bu uyarıyı kaldırın. Destek yaşam döngüsü @ 1@ 2Şablon: Webachiv / IABot / www.es2000.de
  3. Microsoft, Windows Small Business Server 2008 ve Windows Essential Business Server 2008'in Genel Kullanılabilirliğini Duyurdu ( İnternet Arşivi'nde 25 Aralık 2008'den itibaren Memento )
  4. VMware View 3 VMware Açıkladı Genel Durumu, yönetme Ölçekleme ve Kişiselleştirme Ground-Breaking Avansı ile Sanal Masaüstü Ortamları ( Memento içinde 5 Aralık 2008 , Internet Archive )
  5. Yayın Aşamaları ve Kriterleri. (Artık çevrimiçi olarak mevcut değil.) İçinde: cs.pomona.edu. Arşivlenmiş orijinal üzerinde 11 Temmuz 2016 ; 24 Temmuz 2016'da erişildi . Bilgi: Arşiv bağlantısı otomatik olarak eklendi ve henüz kontrol edilmedi. Lütfen orijinal ve arşiv bağlantısını talimatlara göre kontrol edin ve ardından bu uyarıyı kaldırın. @ 1@ 2Şablon: Webachiv / IABot / www.cs.pomona.edu
  6. ^ Johnathan Nightingale: Her Altı Haftada. In: blog.mozilla.org. 18 Temmuz 2011, 24 Temmuz 2016'da erişildi .
  7. Jens Ihlenfeld: Firefox 6 haftada bir, ancak sürüm numarasıyla devam ediyor. golem.de , 26 Ağustos 2011, 24 Temmuz 2016'da erişildi .