Eklentim yıllarca depoda olmasına ve 300.000'den fazla indirmeye sahip olmasına rağmen, kaplumbağa svn aracılığıyla bir eklentiyi güncellemek için kullanılan prosedürde biraz clueless olduğumu söylemekten utanıyorum!
Olma. SVN birçok insan için zor olabilir ... bu yüzden adım adım ilerleyelim ...
Şimdiye kadar yaptığım şey bu.
- memnun olana kadar yerelde eklenti güncellemelerini kodla
- yerel eklenti klasörümdeki tüm dosyaları / trunk / dizinine kopyala (eklenti ve benioku dosyasında sürüm numaraları var)
- trunk dizinini yap
- trunk dizinine sağ tıklayın ve şube / etiket oluştur'u seçin ve / tags / dizinindeki bir klasöre kopyalanacak şekilde ayarlayın.
Bu doğru ve doğru sırada mı? değilse, doğru yol nedir?
Neredeyse ...
İzlemeniz gereken adımlar :
- Eklenti güncellemelerinden memnun olana kadar yerel olarak kodlayın
readme.txtDosyanızdaki "kararlı" etiketi yeni sürüm numarasıyla eşleşecek şekilde artırın- Yerel güncellemelerinizi
/trunkyerel eklenti klasörünün dizinine kopyalayın
- Depodaki değişiklikleri kaydetmek için tüm eklentiyi taahhüt edin
/trunk
- Sağ tıklayın
/trunkve yeni bir etiket oluşturun, /tags/X.X.Xburada xxx'in "kararlı" etiketinde aynı sürüm olduğu yere kopyalayın readme.txt(2. adım)
- Etiketi kaydetmek için tüm eklentiyi taahhüt edin
bazı nedenlerden dolayı, son güncellememde 2.8.1 sürümünden 2.81.2 sürümüne gittim, bu, bir sonraki sürüm numarasını 2.9?
Bingo. 2.81.2 sürümünü güncelleme olarak taahhüt ettiyseniz ve kullanıcılar bu güncelleştirmeyi gerçekten indirdiyse, yayınladığınızda 2.9 sürümünü görmezler.
wordpress en son sürümün hangisi olduğunu ve kullanıcının sürümünü güncellemesi gerekip gerekmediğini nasıl belirler? version_compare yapıyor mu? sadece uygun php sürüm biçimi ile çalışır değil mi? Örneğin. 2.9.2, 2.81.2'den daha düşük bir sürüm olarak kabul edilir? (çünkü anladığım kadarıyla, version_compare soldan başlar ve her basamak için daha yüksek / düşük karşılaştırır, böylece 9 81'den az kabul edilir)
Kesinlikle. Standart bir PHP sürüm karşılaştırması, 81> 9 olduğu için 2.81.2 sürümünün 2.9'dan daha yeni bir sürüm olduğunu görecektir .
Bir sonraki sürüm 3.0'ı yayınlamanızı, daha sonra bu tür yazım hatalarını önlemek için gelecekte sürüm oluştururken çok dikkatli olmanızı öneririz .
eklentinin çalışmasını gerçekten etkilemeyen kodda aptalca bir hata tespit edersem, belki bir yazım hatası veya ek bir görüntü. Eklentinin herhangi bir yeni indirmesinin değişikliği içermesini sağlamak için ne düzenler ve taahhüt ederim?
ve etiket klasörünü düzenlemek ve her ikisini birden yapmak zorunda mıyım?
Küçük bir değişiklik yapmanız gerekiyorsa, bunu bir bakım sürümü olarak düşünün . Genellikle bu tür bir sürüm şeması takip:
2 . 1 . 3 . 5
major minor maint build
Yalnızca dahili olarak veya beta sürümleri için kullandığım derleme numaraları ... Size bir dosyayı el ile e-postayla göndermedikçe neredeyse hiçbir zaman bir derleme numarası görmeyeceksiniz (WordPress güncellemelerini bozmayacak yayın öncesi sürümleri nasıl dağıtabileceğim) .
Canlı sürümde bir hata fark edersem, hızlı bir yama yapacağım ve bir bakım sürümü yayınlayacağım. Diyelim ki bir eklentinin 2.2 sürümünü yayınladım ve birisi noConflict () modunda jQuery'yi çağırmayı unuttuğumu fark etti. Hızlı bir yama yapacağım ve hemen 2.2.1'i bırakacağım.
Sürümdeki artış, WordPress'i güncelleştirmeyi tanımaya ve sürüm 2.2'yi zaten yüklemiş olan herkese düzeltmeyi sağlamaya zorlayacaktır.
Bir bakım sürümünü serbest bırakmak için, sistemin tam sürümünü yayınlıyormuş gibi aynı adımları izlemeniz gerekir . Yani değişiklikler yapın, sürümü readme.txtartırın /trunk, işleme koyun , etiketleyin vb.
Ancak bir şeyi etiketledikten sonra bir daha asla değiştiremezsiniz. /tagsKlasörünüzü zaman içinde donmuş olarak düşünün . Bu klasördeki her sürüm, eklentinizin belirli bir zamandaki anlık görüntüsüdür. Sen gerektiğini asla herhangi bir dosya değiştirmek /tagsdoğrudan klasöre.
Kendinizi iyi bir fikir olabileceğini düşünüyorsanız, kendinizi başınızın arkasına koyun ve bunun yerine bir bakım sürümü yayınlayın :-)
Piet'in belirttiği gibi, daha önce adım adım talimatlar yazdım ... ama site ekran görüntülerimi kaybetmiş görünüyor. Kendi sitemde barındırılan Tortoise'un ekran görüntülerine sahip aynı adım adım kılavuzun başka bir sürümü: http://eamann.com/tech/how-to-publish-a-wordpress-plugin-subversion/