Apakah ada kebalikan dari istilah "Backporting"?

20

Seperti yang saya mengerti, istilah "Backporting" digunakan untuk menggambarkan perbaikan yang diterapkan dalam versi masa depan yang juga porting ke versi sebelumnya. Definisi Wikipedia adalah sebagai berikut:

Backporting adalah tindakan mengambil modifikasi perangkat lunak tertentu (tambalan) dan menerapkannya pada versi perangkat lunak yang lebih lama daripada yang awalnya dibuat. Ini merupakan bagian dari langkah pemeliharaan dalam proses pengembangan perangkat lunak ...

Sebagai contoh:

  • Masalah ditemukan dan diperbaiki di V2.0. Perbaikan yang sama porting dan diterapkan ke V1.5.

Apa istilahnya ketika ini dilakukan dalam arah yang berlawanan?

  • Masalahnya ditemukan dan diperbaiki di V1.5. Perbaikan yang sama porting dan diterapkan ke V2.0.

Apakah istilah "Backporting" masih berlaku? Atau adakah istilah seperti "Forwardporting" (yang secara mengejutkan terdengar seperti "Port Forwarding")?

terminology maintenance Avian00
sumber
1
Bagaimana dengan "menyebarkan"?
Gill Bates

Jawaban:

28

Ini sama dengan kebalikan dari garis miring terbalik. Semua orang ingin menyebutnya garis miring, tetapi sebenarnya itu hanya garis miring. Kebalikan dari backporting hanyalah "porting."

Karl Bielefeldt
sumber
"Porting" adalah istilah yang lebih umum dan dapat berlaku untuk transfer kode apa pun, bahkan antar bahasa. Di perusahaan saya, kami menggunakan "porting-maju" untuk kasus khusus yang dijelaskan dalam pertanyaan ini.
Marko Topolnik
14

Ini biasanya tidak terjadi karena Anda akan memperbaiki masalah tersebut di basis kode V2.0, dan secara opsional mendukungnya. :) Dalam hal kontrol versi, ini hanya disebut merging.

awdz9nld
sumber
3
Ini memang terjadi karena V1.x dan V2.x hidup berdampingan dan dipertahankan secara paralel, masing-masing pada cabang pemeliharaannya sendiri. Bug lintas-versi dapat ditemukan dan diperbaiki di pihak mana pun.
Marko Topolnik
3
Jika V1.5 sudah dirilis, tetapi V2.0 akan dirilis di masa depan, maka Anda terlebih dahulu memperbaiki masalah di V1.5, karena versi ini sudah digunakan oleh pelanggan dan membutuhkan perbaikan lebih mendesak. Setelah itu Anda port perbaikan ke V2.0.
user1364368
@ user1364368 manajemen rilis adalah masalah ortogonal. lebih masuk akal untuk memperbaiki bug di versi terbaru dari basis kode karena mengandung lebih banyak informasi (riwayat perubahannya adalah superset dari riwayat perubahan versi yang lebih lama). pikirkan dengan cara yang berbeda: abaikan bahwa perubahan itu terkait dengan bug. apakah Anda masih lebih suka memperkenalkan perubahan dalam versi yang lebih lama? Apakah Anda, katakanlah, memulai pengembangan fitur dalam versi basis kode yang lebih lama? ini sangat cepat
direduksi menjadi
@ MartinKällman Kepala basis kode (untuk V2.0) mungkin (karena pekerjaan pengembangan saat ini) dalam keadaan yang tidak memungkinkannya mengembangkan perbaikan. Mungkin butuh berhari-hari atau berminggu-minggu sampai kepala basis kode bersih lagi, tetapi Anda tidak bisa menunggu terlalu lama untuk koreksi darurat.
user1364368
1

Saya kira saya akan menggunakan istilah: proof-proof atau, kompatibilitas ke depan :

Dari Wikipedia , bukti masa depan :

Bukti di masa depan: Ungkapan pemeriksaan di masa depan menggambarkan proses eksklusif mencoba mengantisipasi perkembangan di masa depan, sehingga tindakan dapat diambil untuk meminimalkan kemungkinan konsekuensi negatif, dan untuk merebut peluang.

Dan kompatibilitas ke depan :

Kompatibilitas ke depan atau kompatibilitas ke atas (kadang-kadang bingung dengan ekstensibilitas) adalah konsep kompatibilitas untuk desain sistem, seperti misalnya kompatibilitas ke belakang. Kompatibilitas ke depan bertujuan kemampuan suatu desain untuk menerima input dengan anggun yang dimaksudkan untuk versi selanjutnya dari dirinya sendiri.

Atau keduanya "pemeriksaan masa depan melalui kompatibilitas ke depan".

Oh, buzzwordry :)

dukeofgaming
sumber
0

Backporting di arah yang berlawanan hanya porting , tetapi tidak ada alasan untuk melakukan itu dalam konteks yang Anda gambarkan.

Caleb
sumber
0

Saya pikir istilah "backport" hanya merujuk pada tindakan membawa fitur dari rilis baru dari sebuah program ke yang lebih tua dari program yang sama, untuk manfaat masih menggunakannya.

Karena Anda tidak mengembangkan fitur baru pada versi lama, tertutup, tidak ada backport "mundur" (jika Anda, menurut definisi, versinya tidak lama).

Apa yang Anda sebut "forwardport", memperbaiki masalah baik di versi lama dan baru, adalah perbaikan bug atau patch belaka.

Albireo
sumber
-1

Tidak ada istilah yang umum digunakan untuk menggabungkan satu set perubahan dari cabang perangkat lunak yang lebih lama ke yang lebih baru. Kecuali jika cabang terbaru dari perangkat lunak sangat tidak stabil kebanyakan pengembang akan mengembangkan perbaikan bug pada cabang terbaru dari perangkat lunak terlepas dari versi apa bug itu ditemukan. Hal ini dilakukan untuk mengurangi konflik gabungan sejak cabang terakhir dari perubahan perangkat lunak lebih sering daripada cabang yang lebih tua. Setiap bug perangkat lunak yang dilaporkan oleh pelanggan secara definisi dilaporkan dalam versi lebih awal daripada yang diperbaiki karena pelanggan tidak memiliki akses ke cabang terbaru dari perangkat lunak Anda.

Omong kosong Esoterik
sumber
true kecuali pelanggan Anda menginginkan perbaikan SEKARANG.
Alex R
-1

Saya datang ke sini mencari jawaban karena saya sedang menulis komentar komit untuk skenario ini. Mengingat kurangnya jargon aktual untuk situasi umum ini, saya hanya akan mengejanya sebagai "menggabungkan hotfix produksi ke cabang dev".

Alex R
sumber