“Backporting” terimi için tam tersi var mı?


20

Anladığım kadarıyla, "Backporting" terimi, gelecekteki bir sürümde de uygulanan ve önceki bir sürüme taşınan bir düzeltmeyi tanımlamak için kullanılır. Wikipedia tanımı aşağıdaki gibidir:

Backporting , belirli bir yazılım değişikliği (düzeltme eki) alma ve bunu başlangıçta oluşturulduğundan daha eski bir yazılım sürümüne uygulama eylemidir . Bir yazılım geliştirme sürecinde bakım adımının bir parçasını oluşturur ...

Örneğin:

  • V2.0'da bir sorun keşfedildi ve giderildi. Aynı düzeltme taşınır ve V1.5'e uygulanır.

Bunun ters yönde yapıldığı terim nedir?

  • Sorun V1.5'te keşfedildi ve giderildi. Aynı düzeltme taşınır ve V2.0'a uygulanır.

"Backporting" terimi hala geçerli midir? Yoksa "Yönlendirme" gibi bir terim var mı (eğlenceli bir şekilde "Bağlantı Noktası Yönlendirme" gibi görünüyor)?


1
"Yayılma" ne olacak?
Gill Bates

Yanıtlar:


28

Ters eğik çizginin tersi ile aynıdır. Herkes buna ileri eğik çizgi vermek istiyor, ama gerçekten sadece bir "eğik çizgi". Backporting'in tersi basitçe "taşıma" dır.


"Porting" daha genel bir terimdir ve diller arasında bile herhangi bir kod aktarımına uygulanabilir. Şirketimde, bu soruda açıklanan özel durum için "ileri taşıma" kullanıyoruz.
Marko Topolnik

14

Bu genellikle V2.0 kod tabanında söz konusu sorunu gidereceğiniz ve isteğe bağlı olarak geri yükleyeceğiniz için gerçekleşmez. :) Sürüm kontrolü açısından, buna basitçe denir merging.


3
Bu, V1.x ve V2.x bir arada var oldukları ve her biri kendi bakım dalında paralel olarak tutuldukları için olur. Herhangi bir tarafta bir sürümler arası hata bulunabilir ve düzeltilebilir.
Marko Topolnik

3
V1.5 zaten yayınlanmışsa, ancak V2.0 gelecekte piyasaya sürülecekse, önce bu sürümü V1.5'te düzeltirsiniz, çünkü bu sürüm zaten müşteriler tarafından kullanılmaktadır ve daha fazla aciliyet gerektirmektedir. Daha sonra düzeltmeyi V2.0'a bağlarsınız.
user1364368

@ user1364368 sürüm yönetimi dikey bir konudur. daha fazla bilgi içerdiği için kod tabanının en son sürümündeki hatayı düzeltmek daha mantıklıdır (değişiklik geçmişi, eski sürümün değişiklik geçmişinin bir üst kümesidir). farklı bir şekilde düşünün: değişikliğin bir hata ile ilgili olduğunu göz ardı edin. yine de eski bir sürümde değişiklik yapmayı tercih eder misiniz? diyelim ki, kod tabanının eski bir sürümünde özellik geliştirmeye başlar mısınız? bu çok hızlı bir şekilde saçma, geri-özyinelemeli bir geliştirme stratejisine
indirir

@ MartinKällman Kod tabanının başı (V2.0 için) düzeltmeyi geliştirmesine izin vermeyen bir durumda olabilir (mevcut geliştirme çalışmaları nedeniyle). Kod tabanının kafasının yeniden temizlenmesi günler veya haftalar alabilir, ancak acil durum düzeltmesi için bu kadar uzun süre bekleyemezsiniz.
user1364368

1

Şu terimleri kullanacağımı tahmin ediyorum: geleceğe hazırlanma veya alternatif olarak ileri uyumluluk :

Geleceğe yönelik Wikipedia'dan :

Gelecek kanıtı: Gelecek kanıtı ifadesi, gelecekteki gelişmeleri öngörmeye çalışmak için münhasır süreci açıklar, böylece olası olumsuz sonuçları en aza indirmek ve fırsatları yakalamak için harekete geçilebilir.

Ve ileri uyumluluk :

İleri uyumluluk veya yukarı uyumluluk (bazen genişletilebilirlikle karıştırılır), sistem tasarımı için, örneğin geriye dönük uyumluluk gibi bir uyumluluk konseptidir. İleri uyumluluk, bir tasarımın kendisinin sonraki sürümlerine yönelik girdiyi zarif bir şekilde kabul etme yeteneğini amaçlamaktadır.

Veya her ikisi de "ileri uyumluluk ile geleceğe hazır".

Ah moda sözcük :)


0

Backporting ters yönde sadece bir taşıma ama açıkladığınız bağlamda bunu yapmak için hiçbir neden yok.


0

Bence "backport" terimi, sadece bir programın yeni bir sürümünün bir özelliğini aynı programın eski bir sürümüne getirme eylemini, hala kullanmanın yararları için ifade eder.

Eski, kapalı sürümlerde yeni bir özellik geliştirmediğiniz için "ters" backporting yoktur (tanım gereği sürüm eski değilse).

Hem eski hem de yeni bir sürümde bir sorunu gidermek için "ileriye dönük" olarak adlandırdığınız şey, yalnızca bir hata düzeltme ya da düzeltme ekidir.


-1

Eski bir yazılım dalından daha yeni bir dalda bir dizi değişikliği birleştirmek için yaygın olarak kullanılan bir terim yoktur. Yazılımın en son dalı son derece dengesiz değilse, çoğu geliştirici, hatanın hangi sürümde bulunduğuna bakılmaksızın yazılımın en son dalında hata düzeltmeleri geliştirecektir. Bu, yazılımın en son dalı değiştiğinden beri birleştirme çakışmalarını azaltmak için yapılır. daha yaşlı dallardan daha sık. Bir müşteri tarafından bildirilen herhangi bir yazılım hatası, müşterinin yazılımınızın en son şubesine erişimi olmadığından, tanımı gereği düzeltilenden daha önceki bir sürümde bildirilir.


müşteriniz ŞİMDİ bir düzeltme istemedikçe true.
Alex R

-1

Buraya bir cevap aramaya geldim çünkü bu senaryo için kesin bir yorum yazıyorum. Bu yaygın durum için gerçek jargon eksikliği göz önüne alındığında, bunu "üretim düzeltmelerini dev dalına birleştirmek" olarak anlatacağım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.