Çoğu kişi e-pin satış sistemi alırken tek bir soruya odaklanır: "Fiyatı ne?" Sonra ikinci soru gelir: "Kurulum dahil mi?" Üçüncü soru neredeyse hiç sorulmaz, oysa işini iki yıl sonra ayakta tutacak olan tam da o sorudur. O soru şudur: bu e-pin scripti hangi takvimle güncelleniyor, hangi sürümü ne kadar süre destekleniyor? Satın alma anında görünmeyen bu detay, sistemin ömrünü belirleyen tek değişkendir.
Sektörde yıllardır süren sessiz bir alışkanlık var: satıcı sana bir kurulum teslim eder, ilk hafta ilgilenir, sonra ekip yeni bir sürüm koluna geçer ve senin kurulumun olduğu yerde kalır. Altı ay sonra PHP sürümü yükselir, bir ödeme sağlayıcısı API'sini değiştirir, bir bayi entegrasyonu imza formatını yeniler. Sen de o anda öğrenirsin ki elindeki dijital ürün satış scripti artık "destek dışı" bir sürümdedir. Bu yazıda o perdeyi aralayıp, güncelleme politikasının gerçekte nasıl okunacağını, hangi maddelerin tuzak olduğunu ve sağlıklı bir sürüm desteğinin nasıl göründüğünü tek tek göstereceğim.
Güncelleme ile yama aynı şey mi? Satıcıların bu kelimeyi neden karıştırmasına izin veriyorsun?
Bir e-pin satış scripti için "güncelleme" tek bir şey değildir; en az dört farklı iş anlamına gelir. Birincisi güvenlik yaması: bir açığı kapatan, davranışı değiştirmeyen, mümkün olan en kısa sürede uygulanması gereken müdahale. İkincisi uyum güncellemesi: PHP, MariaDB, cURL veya bir ödeme sağlayıcısının kendi tarafında yaptığı değişikliğe ayak uydurma. Üçüncüsü özellik sürümü: yeni modül, yeni panel ekranı, yeni rapor. Dördüncüsü yeniden yapılandırma: kod tarafında borç temizliği, performans kazancı.
Sözleşmede "1 yıl ücretsiz güncelleme" yazıyorsa, hangi kategoriyi kapsadığını sormak zorundasın. Çoğu durumda bu ifade yalnızca özellik sürümlerini kapsar; yani asıl ihtiyacın olan uyum ve güvenlik tarafı "bakım paketi" adı altında ayrı fiyatlanır. Tersi de olur: yalnızca yama verilir, yeni özellikler için sürüm atlaması ücretlidir. Doğru soru şudur: "Bu dört kalemden hangisi hangi süreyle, hangi bedelle kapsanıyor?" Pinova tarafında bu ayrım açık yazılır, çünkü belirsizlik yaşandığı anda maliyet senin üzerine kalır.
"Ömür boyu lisans" neden ömür boyu destek demek değil?
Pazarlama dilinde en çok istismar edilen ifade bu. Ömür boyu lisans, kodu süresiz kullanma hakkıdemektir. Kodun güncellenmeye devam edeceği anlamına gelmez. Elinde 2023'te yazılmış bir epin yazılım kurulumu olabilir; lisansın süresiz, kullanım hakkın tartışmasız, ama sunucun PHP 8.4'e geçtiğinde çalışmıyorsa o hakkın pratik değeri sıfırdır.
Sağlıklı model şu üç bileşeni ayırır: lisans hakkı (süresiz olabilir), güncelleme erişimi (dönemsel), teknik destek (yanıt süresi taahhütlü). Bir satıcı bu üçünü tek kelimeye sıkıştırıyorsa, ileride hangi konuda hak talep edeceğini bilemezsin. Teklifi aldığın anda bu üç satırı ayrı ayrı yazılı isteyeceksin. Yazılı olmayan taahhüt, ilk kriz gününde "biz onu demek istememiştik"e dönüşür.
Bir yıllık sürüm çalışmasının gerçek dağılımı
- Güvenlik yamaları 40%
- Yeni özellik sürümleri 30%
- Entegrasyon / API uyumu 20%
- Performans ve kod temizliği 10%
Sürüm numaraları sana ne söyler, ne saklar?
Ciddi bir dijital ürün satış yazılımı anlamlı sürümleme kullanır: MAJOR.MINOR.PATCH. Üçüncü hane değiştiyse davranış aynı kalır, sadece hata düzeltilmiştir; güncellemesi risksizdir. İkinci hane değiştiyse yeni yetenek gelmiştir, geriye dönük uyum korunur. Birinci hane değiştiyse kırıcı değişiklik vardır: tema dosyaları, kanca noktaları veya veritabanı şeması değişmiş olabilir.
Tuzak burada: bazı satıcılar her küçük yamada birinci haneyi büyütür, çünkü "v7" kulağa "v3.1.4"ten daha güçlü gelir. Sonuç olarak sen hangi güncellemenin riskli olduğunu ayırt edemezsin ve her seferinde canlı sistemi kumar oynar gibi güncellersin. Sürüm notu olmayan güncelleme, güncelleme değildir. Her sürümle birlikte "neler değişti, neler kırılabilir, hangi dosya elle düzenlenmeli" bilgisini almıyorsan, o güncelleme senin için bir bilinmezdir.
| Sürüm tipi | Ne değişir | Canlıya alma riski | Uygulama penceresi | Ön koşul |
|---|---|---|---|---|
| PATCH (x.x.5) | Hata ve güvenlik düzeltmesi | Çok düşük | 24-72 saat | Dosya yedeği |
| MINOR (x.3.0) | Yeni modül, yeni alan | Düşük-orta | 1-2 hafta | Test kurulumu |
| MAJOR (4.0.0) | Şema ve arayüz değişimi | Yüksek | 3-6 hafta | Tam yedek + geri dönüş planı |
| Hotfix | Aktif istismar edilen açık | Kabul edilmeli | Aynı gün | Bakım modu |
| Uyum yaması | PHP / ödeme API uyumu | Orta | Sağlayıcı takvimi | Sağlayıcı test anahtarı |
LTS mantığını e-pin işine nasıl taşırsın?
Kurumsal yazılım dünyasında uzun dönem destek (LTS) kavramı vardır: belirli bir sürüm hattı, yeni özellik almasa da güvenlik ve uyum yaması almaya devam eder. Bu model e-pin işletmesi için birebir uygundur, çünkü senin işin sürekli yeni ekran değil kesintisiz sipariş akışı ister.
Pratikte kurgu şöyle olur: canlı sistemin bir LTS hattında durur, yeni özellikler önce test alan adında denenir, sen sadece hazır olduğunda ana hatta geçersin. Bu düzen iki şeyi birlikte verir: kararlılık ve gelişim. Karşı senaryo tanıdık gelir — her güncellemede canlı sistemin kobay olması, satış saatinde tema bozulması, gece yarısı geri dönüş arayışı. Kararlılık bir yetenek değil, bir politika sonucudur. Sistemin yetenek listesini özellikler bölümünde inceleyebilirsin ama gerçek soru her zaman şu kalır: bu yetenekler hangi disiplinle güncel tutuluyor?
Destek biterken ne oluyor? "Sessiz sona" karşı erken uyarı
En yıkıcı senaryo, desteğin bir gün aniden kesilmesi değil; kimsenin sana bunu söylememesidir. Sürüm hattın destek dışına düştüğünde bunu bir arıza anında öğrenmek, hem çözüm süresini uzatır hem pazarlık gücünü sıfırlar. Sağlıklı politikada üç tarih baştan bellidir: aktif geliştirme bitişi, yalnızca güvenlik yaması dönemi ve tam destek sonu. Bu takvim elindeyse geçişi sen planlarsın; elinde değilse geçiş seni bulur.
Bir de göç maliyeti meselesi var. Eski hattan yeniye çıkarken özel yazılmış tema, elle eklenmiş bayi entegrasyonu ve veritabanına sonradan sokulmuş alanlar sorun çıkarır. Bunları kayıt altında tutan işletme bir günde geçer; tutmayan işletme haftalarca kayıp yaşar. Özelleştirme envanteri tutmak, güncelleme politikasının senin tarafındaki yarısıdır.
Her güncellemeden önce dosya + veritabanı yedeğini ayrı bir dizine tarih etiketiyle al, bakım modunu aç, güncellemeyi uygula, sonra tek bir test siparişi geçirip teslimatın gerçekten ulaştığını doğrula. Bu ritüel, yıl içinde yaşayacağın en pahalı gecenin sigortasıdır.
Teklif alırken hangi soruları sorarsan satıcı gerçeği söylemek zorunda kalır?
Genel sorular genel cevap alır. Spesifik sorular ise kayıt altına girer. Aşağıdaki kontrol listesini teklif görüşmesinde tek tek işaretle; cevaplanmayan her satır, ileride ödeyeceğin faturadır. Fiyatlandırma ile destek kapsamının nasıl eşleştiğini fiyat bölümünde karşılaştırabilirsin.
| Kontrol maddesi | Neden kritik | Kabul edilebilir cevap | Durum |
|---|---|---|---|
| Güvenlik yaması süresi yazılı mı? | Açık kapanmazsa sipariş verisi risk altında | "En az 24 ay, ücretsiz" | ☐ |
| Sürüm notu yayınlanıyor mu? | Kırıcı değişikliği önceden görmek için | Her sürümde yazılı değişiklik listesi | ☐ |
| Test kurulumu hakkı var mı? | Canlıyı kobay yapmamak için | Aynı lisansla 1 test alanı | ☐ |
| Geri dönüş prosedürü tanımlı mı? | Başarısız güncellemede kayıp süreyi keser | Adım adım dokümante edilmiş | ☐ |
| Ödeme/bayi API uyumu kapsamda mı? | Dış sağlayıcı değişimi seni durdurmasın | Uyum yaması ücretsiz | ☐ |
| Özelleştirmelerim korunuyor mu? | Tema/kod ezilmesi en sık kayıp nedeni | Çocuk tema veya kanca yapısı | ☐ |
| Destek sonu takvimi paylaşılıyor mu? | Göçü sen planlayabilmelisin | Üç tarihli açık takvim | ☐ |
Güncelleme politikası belirsiz bir sistemle büyüyemezsin
Pinova, e-pin ve dijital ürün satan işletmeler için yazılı sürüm disiplini, test alanı ve sürüm notu ile gelen lisanslı bir satış yönetim yazılımıdır. Kurulumunu bir yıl sonra da güncelleyebileceğin bir zemine kur.
E-pin scriptimi her sürümde güncellemek zorunda mıyım?
Hayır. Güvenlik yamalarını ve ödeme/bayi uyum yamalarını mutlaka uygulaman gerekir. Özellik sürümlerini ise iş takvimine göre erteleyebilirsin; önemli olan destek dışı bir hatta düşmemektir.
Güncelleme temamı ve özel değişikliklerimi siler mi?
Doğru yapılandırılmış bir kurulumda silmez. Özelleştirmelerin çekirdek dosyalar yerine ayrı tema ve kanca katmanında tutulması gerekir. Çekirdeği elle düzenlediysen her güncelleme o değişikliği ezer.
Ömür boyu lisans aldım, güncellemeler de ömür boyu mu?
Genellikle hayır. Lisans kullanım hakkıdır; güncelleme erişimi ve teknik destek ayrı kalemlerdir. Sözleşmede bu üç başlığın ayrı ayrı süresi yazılı olmalı.
Eski sürümde kalmanın somut riski nedir?
Üç risk var: kapatılmamış güvenlik açıkları, sunucu ortamı yükseltildiğinde çalışmayan kod ve ödeme sağlayıcısı API değiştirdiğinde duran tahsilat. Üçü de doğrudan ciro kaybına dönüşür.
Bir e-pin satış sisteminin kalitesini kurulum gününde değil, on beşinci ayında anlarsın. O gün seni ayakta tutacak şey ekran sayısı değil; yazılı bir güncelleme politikası, anlamlı sürüm notları ve geri dönebileceğin bir plandır. Bu disiplinin panele nasıl yansıdığını kendi gözünle görmek istersen canlı demo üzerinden sipariş akışını, teslimat kayıtlarını ve yönetim ekranlarını inceleyip kararını somut veriyle verebilirsin.