Bu sayfa son olarak 2022-01 tarihinde güncellendi.

Önce yeni geliştirici rehberi bölümünü okuyun.

Temel rehberler ve kodlama biçemi

Aşağıdakilerin çoğu, açık kaynak veya ticari bir programlama ortamında çalışan herkes için sağduyulu bir yaklaşım olmalıdır. Aşağıdaki konular çoğunlukla ana geliştirme dalı i2p.i2p için geçerlidir. Diğer dallar, eklentiler ve dış uygulamalar için yönergeler önemli ölçüde farklı olabilir. Rehberlik etmesi için uygun geliştiriciye danışın.

Topluluk

  • Lütfen yalnızca "kod yazmakla yetinmeyin". Yapabiliyorsanız, diğer geliştirme işlemlerine de katılın: IRC, zzz.i2p ve i2pforum.i2p üzerinde geliştirme tartışmaları yapmak ve destek vermek; deneme yapmak; hataları raporlamak ve yanıtlamak; belgelendirme; kod incelemeleri; vb.
  • Aktif geliştiriciler, #i2p-dev IRC kanalında periyodik olarak bulunmalıdır. Var olan yayın döngüsünü anlayın. Özellik dondurma, etiket dondurma ve bir sürümün gönderilme teslim tarihi gibi aşamalara bağlı kalın.

Yayın döngüsü

Our normal release cycle is 6-12 weeks. Following are the approximate deadlines within a typical 8-week cycle. Actual deadlines for each release are set by the lead developer after consultation with the full team.

  • Önceki sürümden 1-2 gün sonra: Dal içine göndermeye izin verilir.
  • Önceki sürümden 2-3 hafta sonra: Büyük değişiklikleri diğer dallardan ana gövdeye almak için son tarih.
  • Yayınlanmadan 4-5 hafta önce: Yeni ana sayfa bağlantıları istemek için son tarih.
  • Yayınlanmadan 3-4 hafta önce: Özellik dondurma. Önemli yeni özellikler için son tarih.
  • Yayınlanmadan 2-3 hafta önce: Varsa, yeni ana sayfa bağlantı isteklerini gözden geçirmek için proje toplantısı.
  • 10-14 days before release: String freeze. No more changes to translated ("tagged") strings. Push strings to Transifex, announce translation deadline on Transifex.
  • 10-14 days before release: Feature deadline. Bug fixes only after this time. No more features, refactoring or cleanup.
  • 3-4 days before release: Translation deadline. Pull translations from Transifex and check in.
  • 3-4 days before release: Checkin deadline. No checkins after this time without the permission of the release builder.
  • Yayınlanmadan saatler önce: Kodu incelemek için son tarih.

Git

  • Daha önce Git kullanmamış olsanız bile, dağıtılmış kaynak kodu kontrol sistemleri hakkında temel bilgilere sahip olun. Gerek duyarsanız yardım isteyin. Bir kez itildiğinde, gönbderimler sonsuza kadar kalır ve geri alınamaz. Lütfen dikkatli olun. Daha önce Git kullanmadıysanız, bebek adımlarıyla başlayın. Bazı küçük değişiklikler gönderin ve nasıl gittiğini görün.
  • Değişikliklerinizi göndermeden önce deneyin. Deneme öncesi gönderme geliştirme modelini yeğliyorsanız, kendi geliştirme dalınızı kullanın ve iyi çalıştığında i2p.i2p üzerine gönderin. Yapımı bozmayın. Gerilemelere neden olmayın. Bunu yaparsanız (olabilir), lütfen değişikliğinizi ittikten sonra uzun bir süre ortadan kaybolmayın.
  • Yaptığınız değişiklik önemsizse ya da başkalarının denemesini istiyorsanız ve değişikliğinizin denendiğini bilmek için iyi raporlara gerek duyuyorsanız, history.txt dosyasına bir gönderme yorumu ekleyin ve RouterVersion.java içindeki yapım sürümünü artırın.
  • Göndermeden ve itmeden önce en son revizyonu çekmek için 'git pull' yaptığınızdan emin olun. Yanlışlıkla revizyondan ayrılırsanız, en kısa sürede birleştirin ve gönderin. Birleştirme işlemini başkalarına yaptırmayı alışkanlık haline getirmeyin.
  • Yayın döngüsünün sonlarında ana i2p.i2p dalına büyük değişiklikler göndermeyin. Bir proje birkaç gününüzden fazlasını alacaksa, Git üzerinde kendi dalınızı oluşturun ve geliştirmeleri orada yapın. Böylece yayınları engellemezsiniz.

Kodlama biçemi

  • Kodun çoğunda kodlama biçemi olarak, girinti için 4 boşluk kullanılır. Sekmeleri kullanmayın. Kodu yeniden biçimlendirmeyin. IDE veya düzenleyiciniz her şeyi yeniden biçimlendirmek istiyorsa, kontrolü ele alın. 4 boşluğun zahmetli olduğunu biliyoruz, ancak belki düzenleyicinizi uygun şekilde yapılandırabilirsiniz. Bazı yerlerde kodlama biçemi farklıdır. Sağduyulu olun. Üzerinde çalıştığınız dosyamın biçemine uygun davranın.
  • Tüm yeni herkese açık ve pakete özel sınıflar ve yöntemler için Javadocs gerekir. @since release-number ekleyin. Yeni özel yöntemler için Javadocs istenir.
  • Eklenen herhangi bir Javadocs için, herhangi bir doklint hatası veya uyarısı olmamalıdır. Kontrol etmek için Oracle Java 14 veya üzerinde 'ant javadoc' çalıştırın. Tüm paragraflar @param satırlarına sahip olmalıdır, geçerli olmayan tüm yöntemlerde @return satırları bulunmalıdır. Atılan tüm istisnalarda @throws satırları bulunmalı ve HTML hatası olmamalıdır.
  • Core/ (i2p.jar) içindeki sınıflar ve i2ptunnel bölümleri resmi API parçasıdır. Bu API yazılımına dayanan birkaç ağaç dışı eklenti ve diğer uygulama vardır. Uyumluluğu bozan herhangi bir değişiklik yapmamaya dikkat edin. Genel kullanıma yönelik olmadıkça API üzerine yöntemler eklemeyin. API yöntemleri için Javadocs açık ve eksiksiz olmalıdır. API üzerinde ekleme veya değişiklik yaparsanız, web sitesindeki belgeleri de güncelleyin (i2p.www dalı).
  • Tag strings for translation where appropriate, which is true for all UI strings. Don't change existing tagged strings unless really necessary, as it will break existing translations. Do not add or change tagged strings after the "tag freeze" in the release cycle so that translators have a chance to update before the release.
  • Olabiliyorsa genel ve yinelenen sınıflar kullanın. I2P oldukça fazla sayıda arka plan işlemi kullanan bir uygulamadır.
  • Hata ayıklayıcıların bulduğu yaygın Java tuzaklarına aşina olun. Ayrıntılı bilgi edinmek için 'ant findbugs' çalıştırın.
  • We require Java 8 to build and run I2P as of release 0.9.47. Do not use Java 7 or 8 classes or methods in embedded subsystems: addressbook, core, i2ptunnel.jar (non-UI), mstreaming, router, routerconsole (news only), streaming. These subsystems are used by Android and embedded applications that require only Java 6. All classes must be available in Android API 14. Java 7 language features are acceptable in these subsystems if supported by the current version of the Android SDK and they compile to Java 6-compatible code.
  • Try-with-resources cannot be used in embedded subsystems as it requires java.lang.AutoCloseable in the runtime, and this is not available until Android API 19 (KitKat 4.4).
  • The java.nio.file package cannot be used in embedded subsystems as it is not available until Android API 26 (Oreo 8).
  • Other than the above limitations, Java 8 classes, methods, and constructs may be used in the following subsystems only: BOB, desktopgui, i2psnark, i2ptunnel.war (UI), jetty-i2p.jar, jsonrpc, routerconsole (except news), SAM, susidns, susimail, systray.
  • Plugin authors may require any minimum Java version via the plugin.config file.
  • İlkel türler ve sınıflar arasında açıktan dönüştürme; otomatik kutulamaya/kutudan çıkarmaya güvenmeyin.
  • URL kullanmayın URI kullanın.
  • Exception yakalamayın. RuntimeException ve kontrol edilen istisnaları ayrı ayrı yakalayın.
  • UTF-8 karakter kümesi bağımsız değişkeni olmadan String.getBytes() kullanmayın. DataHelper.getUTF8() veya DataHelper.getASCII() kullanabilirsiniz.
  • Dosyaları okurken veya yazarken her zaman bir UTF-8 karakter kümesi belirtin. DataHelper araçları yardımcı olabilir.
  • String.toLowerCase() veya String.toUpperCase() kullanırken her zaman bir yerel ayar (Locale.US gibi) belirtin. Bir yerel ayar belirlenemediğinde String.equalsIgnoreCase() kullanmayın.
  • String.split() kullanmayın. DataHelper.split() kullanın.
  • Don't add code to format dates and times. Use DataHelper.formatDate() and formatTime().
  • InputStreams ve OutputStreams için son bloklarda kapalı olduğundan emin olun.
  • Yalnızca bir satır bile olsa tüm for ve while blokları için {} kullanın. if, else veya if-else bloğu için {} kullanırsanız, tüm bloklar için kullanın. Tek bir satıra "} else {" koyun.
  • Alanları olabildiğince sonda belirtin.
  • Durağan alanlarda, I2PPAppContext, RouterContext, Log veya yöneltici veya bağlam ögelerine yapılan diğer referansları saklamayın.
  • Yapımcılarda arka plan işlemleri başlatmayın. Thread yerine I2PAppThread kullanın.

Logging

The following guidelines apply to the router, webapps, and all plugins.
  • For any messages not displayed at the default log level (WARN, INFO, and DEBUG), unless the message is a static string (no concatenation), always use log.shouldWarn(), log.shouldInfo(), or log.shouldDebug() before the log call to avoid unnecessary Object churn.
  • Log messages that may be displayed at the default log level (ERROR, CRIT, and logAlways()) should be brief, clear, and understandable to a non-technical user. This includes exception reason text that may also be displayed. Consider translating if the error is likely to happen (for example, on form submission errors). Otherwise, translation is not necessary, but it may be helpful to search for and reuse a string that is already tagged for translation elsewhere.
  • Log messages not displayed at the default log level (WARN, INFO, and DEBUG) are intended for developer use, and do not have the above requirements. However, WARN messages are available in the Android log tab, and may be of assistance to users debugging issues, so use some care with WARN messages as well.
  • INFO and DEBUG log messages should be used sparingly, especially in hot code paths. While useful during development, consider removing them or commenting them out after testing is complete.
  • Do not log to stdout or stderr (wrapper log).

Lisanslar

  • Yalnızca kendi yazdığınız kodu gönderin. Diğer kaynaklardan herhangi bir kod veya kitaplık jar dosyası göndermeden önce, neden gerekli olduğunu gerekçelendirin, lisansın uyumlu olduğunu doğrulayın, ve baş geliştiriciden onay alın.
  • Dış kod veya jar dosyası eklemek için onay alırsanız, ve binary dosyalar herhangi bir Debian veya Ubuntu paketinde varsa, dış paketi kullanmak için derleme ve paketleme seçeneklerini uygulamanız gerekir. Değiştirilecek dosyaların kontrol listesi: build.properties, build.xml, debian/control, debian/i2p-router.install, debian/i2p-router.links, debian/rules, sub-build.xml
  • Dış kaynaklardan gönderilen tüm görseller için, öncelikle lisansın uyumlu olduğunu doğrulamak sizin sorumluluğunuzdadır. Gönderme açıklamasına lisans ve kaynak bilgilerini ekleyin.

Hatalar

  • Trac kayıtlarını yönetmek herkesin işidir, lütfen yardım edin. Atandığınız veya yardımcı olabileceğiniz kayıtlar için trac.i2p2.de izleyin. Yapabiliyorsanız kayıtları atayın, kategorilere ayırın, yorum yapın, düzeltin veya kapatın.
  • Yeni geliştiriciler bir hatayı düzelterek başlamalıdır. trac üzerinde 'easy' anahtar sözcüğüyle hataları arayın. Bir düzeltme yaptığınızda, yamanızı kayıda ekleyin ve 'review-needed' anahtar sözcüğünü ekleyin. Tam olarak incelenene ve değişiklikleriniz gönderilene kadar kaydı kapatmayın. Birkaç kayıt için bu işlemi sorunsuz olarak tamamladıktan sonra, aşağıdaki normal süreci izleyebilirsiniz.
  • Düzelttiğinizi düşündüğünüzde bir kaydı kapatın. Kayıtları doğrulamak ve kapatmak için bir deneme ekibimiz yok. Düzelttiğinizden emin değilseniz, kapatın ve şunu notu ekleyin. "I think I fixed it, please test and reopen if it's still broken". Geliştirme yapı numarası veya revizyon numarasını yorum olarak ekleyin ve sonraki sürüm için kilometre taşını ayarlayın.