Ö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

• Please don't just "write code". If you can, participate in other development activities, including: development discussions and support on IRC, i2pforum.i2p; testing; bug reporting and responses; documentation; code reviews; etc.
• 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ü

The 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 release manager 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 son değişiklikleri çekmek için 'git pull' yaptığınızdan emin olun. Yanlışlıkla değişikliklerden 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, sitedeki belgeleri de güncelleyin (i2p.www dalı).
• Uygun olduğunda çeviri için dizgeleri etiketleyin, tüm kullanıcı arayüzü dizgeleri için geçerlidir. Yapılmış çevirileri bozacağından, gerçekten gerekmedikçe var olan etiketli dizgeleri değiştirmeyin. Yayın döngüsünde "etiket dondurma" işleminden sonra etiketli dizgeleri eklemeyin veya değiştirmeyin, böylece çevirmenler yayından önce çevirileri güncelleyebilir.
• 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.
• Java 8 is required 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.

Günlük kaydı

• 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

• Only check in code that you wrote yourself. Before checking in any code or library jars from other sources, justify why it is necessary, verify the license is compatible, and obtain approval from the release manager.
• 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

• Managing issues are everybody's job, please help. Monitor for issues you can help with. Comment on, fix, and close issues if you can.
• New developers should start by fixing issues. When you have a fix, attach your patch to the issue and add the keyword 'review-needed'. Do not close the issue until it's been successfully reviewed and you've checked your changes in. Once you've done this smoothly for a couple of tickets, you may follow the normal procedure below.
• Close an issue when you think you've fixed it. We don't have a test department to verify and close tickets. If you arent sure you fixed it, close it and add a note saying "I think I fixed it, please test and reopen if it's still broken". Add a comment with the dev build number or revision and set the milestone to the next release.