blog: tambah terjemahan "A Proposal for Package Versioning in Go"

2 files changed, 280 insertions, 0 deletions

diff --git a/content/blog/index.adoc b/content/blog/index.adoc
index 8656a5a..b38e1d4 100644
--- a/content/blog/index.adoc
+++ b/content/blog/index.adoc
@@ -51,6 +51,10 @@
 
 ==  Modul
 
+*  link:/blog/versioning-proposal[Proposal untuk versi paket dalam Go], 26
+   Maret 2018.
+   _Russ Cox_
+
 *  link:/blog/using-go-modules[Bagian 1 - Menggunakan Go modul], 19 Maret
    2019.
    _Tyler Bui-Palsulich dan Eno Compton_
diff --git a/content/blog/versioning-proposal/index.adoc b/content/blog/versioning-proposal/index.adoc
new file mode 100644
index 0000000..f418ef1
--- /dev/null
+++ b/content/blog/versioning-proposal/index.adoc
@@ -0,0 +1,276 @@
+=  Proposal untuk Versi Paket dalam Go
+:author: Russ Cox
+:date: 26 Maret 2018
+
+==  Pendahuluan
+
+Delapan tahun yang lalu, tim Go memperkenalkan `goinstall` (yang menyebabkan
+adanya `go get`) dan bersamaan dengannya muncul lah path impor, yang
+ter-desentralisasi dan mirip URL, yang dikenal oleh para pengembang Go sampai
+sekarang.
+Setelah kami merilis `goinstall`, salah satu pertanyaan yang diajukan oleh
+orang adalah bagaimana menerapkan informasi versi.
+Kami akui kami tidak tahu.
+Sepanjang waktu, kami percaya bahwa permasalahan dari versi paket akan lebih
+baik ditangani oleh perkakas tambahan, dan kami mendukung para pengembang lain
+untuk membuatnya.
+Komunitas Go membuat banyak perkakas dengan pendekatan yang berbeda-beda.
+Tiap-tiapnya membantu kami lebih memahami permasalahan yang dihadapi, namun
+pada pertengahan 2016 cukup jelas bahwa sekarang sudah terlalu banyak solusi.
+Kami butuh mengadopsi sebuah perkakas resmi.
+
+Setelah diskusi komunitas di GopherCon pada Juli 2016 yang berlanjut
+sampai musim gugur, kami semua percaya bahwa jawabannya adalah mengikuti
+pendekatan versi paket yang dicontohkan oleh Cargo dari bahasa Rust, dengan
+sebuah tag versi semantik, sebuah manifesto, dan sebuah berkas _pengunci_, dan
+sebuah
+https://research.swtch.com/version-sat[SAT solver]
+yang memutuskan versi mana yang digunakan.
+Sam Boyer memimpin sebuah tim menciptakan Dep, yang mengikuti langkah dasar
+tersebut, dan yang kita gunakan sebagai model untuk integrasi dengan perintah
+`go`.
+Namun semakin kami belajar implikasi dari pendekatan Cargo/Dep, semakin jelas
+bagi saya bahwa Go akan lebih baik bila menggunakan beberapa pendekatan 
+yang berbeda, terutama yang memperhatikan kompatibilitas.
+
+
+==  Impak dari Kompatibilitas
+
+Fitur baru paling penting dari
+https://blog.golang.org/preview-of-go-version-1[Go 1]
+bukanlah sebuah fitur bahasa.
+Melainkan penekanan pada kompatibilitas.
+Sampai pada titik tersebut kami telah melakukan rilis stabil setiap bulan,
+setiap rilis dengan perubahan yang tidak kompatibel.
+Kami melihat adanya akselerasi yang signifikan dalam ketertarikan dan adopsi
+secara langsung setelah rilis dari Go 1.
+Kami percaya bahwa dengan
+https://golang.org/doc/go1compat.html[menjamin kompatibilitas]
+membuat pengembang merasa lebih nyaman bergantung pada Go untuk penggunaan di
+tingkat produksi dan salah satu alasan kunci bahwa Go sekarang menjadi
+terkenal.
+Sejak 2013, link:/doc/faq#get_version[Go FAQ]
+telah mendukung para pengembang paket untuk menyediakan bagi pengguna mereka
+ekspektasi yang sama dari kompatibilitas.
+Kami menyebutnya dengan _aturan kompatibilitas impor_: "Jika sebuah paket lama
+dan sebuah paket baru memiliki path impor yang sama, maka paket yang baru
+haruslah kompatibel dengan paket lama."
+
+Secara independen,
+http://semver.org/[versi semantik]
+telah menjadi standar _de facto_ untuk menentukan versi pada perangkat lunak
+di dalam banyak komunitas bahasa pemrograman, termasuk komunitas Go.
+Dengan menggunakan versi semantik, versi selanjutnya diharapkan supaya
+kompatibel dengan versi sebelumnya, selama masih dalam versi mayor yang sama:
+v1.2.3 haruslah kompatibel dengan v1.2.1 dan v1.1.5, namun v2.3.4 tidak perlu
+kompatibel dengan salah satu diantaranya.
+
+Jika kita mengadopsi versi semantik untuk paket-paket Go, seperti yang para
+pengembang Go harapkan, maka aturan kompatibilitas impor mengharuskan bahwa
+versi mayor yang berbeda harus menggunakan path impor yang berbeda.
+Observasi ini membawa kita ke _semantic import versioning_ (versi impor
+semantik), yang mana versi v2.0.0 mengikutkan versi mayor di dalam path impor:
+"my/thing/v2/sub/pkg".
+
+Setahun yang lalu saya percaya bahwa mengikutkan nomor versi ke dalam
+path impor hanya lah masalah selera, dan saya skeptis bahwa dengan
+menggunakan versi pada path impor tidak terlalu elegan.
+Namun keputusannya ternyata bukanlah karena selera namun karena logis:
+kompatibilitas impor dan versi semantik bersama-sama membutuhkan
+_semantic import versioning_.
+Saat saya menyadari ini, kebutuhan logis tersebut mengejutkan saya.
+
+Saya juga terkejut menyadari bahwa ada rute logika independen kedua  terhadap
+_semantic import versioning_:
+https://talks.golang.org/2016/refactor.article[perbaikan kode secara gradual]
+atau pembaruan kode secara parsial.
+Dalam sebuah program yang besar, adalah hal yang tidak realistis untuk
+berharap semua paket dalam program untuk memperbarui sebuah dependensi
+tertentu dari v1 ke v2 pada saat bersamaan.
+Namun, akan lebih memungkinkan bagi beberapa program tetap menggunakan v1
+sementara bagian lain di-_upgrade_ ke v2.
+Ketika program dibangun, dan hasil akhir program harus mengikutkan
+kedua dependensi v1 dan v2 tersebut.
+Membuat kedua versi tersebut menggunakan path impor yang sama akan
+mengakibatkan kebingungan, melanggar apa yang kita sebut
+_aturan keunikan impor_: paket yang berbeda haruslah memiliki path impor yang
+berbeda.
+Satu-satunya cara untuk pembaruan kode secara parsial, dengan keunikan impor,
+_dan_ versi semantik adalah dengan mengadopsi _semantic import versioning_
+juga.
+
+Tentu saja memungkinkan untuk membangun sistem yang menggunakan versi semantik
+tanpa _semantic import versioning_, tetapi kita akan kehilangan pembaruan kode
+secara parsial atau keunikan impor.
+Cargo membolehkan pembaruan kode secara parsial dengan kehilangan keunikan
+impor: sebuah path impor bisa memiliki arti yang berbeda di bagian yang
+berbeda pada sebuah pembangunan.
+Dep menjamin keunikan impor dengan kehilangan pembaruan kode secara parsial:
+semua paket-paket harus menggunakan satu versi dependensi yang sama,
+menyebabkan kemungkinan adanya program yang besar tidak bisa dibangun ulang.
+Cargo benar dalam memaksa pembaruan kode parsial, yang mana adalah sebuah hal
+yang kritis dalam pengembangan perangkat lunak berskala besar.
+Dep juga benar dengan memaksa keunikan impor.
+Penggunaan direktori "vendor" yang kompleks pada Go dapat melanggar keunikan
+impor.
+Kedua masalah tersebut sangat cukup menantang bagi pengembang dan perkakas
+untuk dipahami.
+Dengan memilih antara pembaruan kode parsial dan keunikan impor membutuhkan
+prediksi yang mana lebih merugikan bila dihilangkan.
+Versi impor semantik membuat kita menghindari pilihan tersebut dan memiliki
+keduanya.
+
+Saya juga cukup terkejut menjumpai berapa banyak kompatibilitas impor
+menyederhanakan pemilihan versi, yang mana merupakan permasalahan menentukan
+versi paket mana yang digunakan untuk sebuah pembangunan.
+Batasan-batasan dari Cargo dan Dep membuat pemilihan versi sama dengan
+https://research.swtch.com/version-sat[pemecahan kepuasan Boolean],
+artinya, bisa sangat mahal untuk menentukan apakah sebuah konfigurasi versi
+yang valid itu benar ada.
+Dan bisa saja banyak konfigurasi yang valid, tanpa ada kriteria untuk memilih
+yang "terbaik".
+Bergantung pada kompatibilitas impor membuat Go menggunakan algoritme yang
+biasa, dengan waktu yang linear untuk menemukan sebuah konfigurasi yang
+terbaik, yang selalu ada.
+Algoritme ini, yang saya sebut dengan
+https://research.swtch.com/vgo-mvs[_minimal version selection_]
+(pemilihan versi minimum), ternyata mengeliminasi kebutuhan untuk berkas
+_lock_ dan _manifest_ yang terpisah.
+Ia menggantinya dengan sebuah berkas konfigurasi yang singkat, disunting
+secara langsung oleh pengembang dan perkakas, yang masih mendukung pembangunan
+yang dapat direproduksi.
+
+Pengalaman kita dengan Dep menunjukkan impak dari kompatibilitas.
+Mengikuti pengembangan Cargo dan sistem sebelumnya, kami merancang Dep untuk
+menyerah dengan kompatibilitas impor supaya dapat mengadopsi versi semantik.
+Saya tidak percaya bahwa kita memutuskan ini secara sengaja;
+kami hanya mengikuti sistem-sistem yang lain.
+Pengalaman awal saat mencoba Dep membantu kita memahami lebih baik
+kompleksitas yang disebabkan oleh adanya path impor yang tidak kompatibel.
+Dengan menghidupkan kembali aturan kompatibilitas impor dengan memperkenalkan
+versi impor semantik menghilangkan kompleksitas tersebut, menghasilkan sistem
+yang lebih simpel.
+
+==  Progres, Prototipe, dan Proposal
+
+Dep dirilis Januari 2017.
+Model dasarnya--kode yang di-tag dengan versi semantik, bersamaan dengan
+sebuah berkas konfigurasi yang menspesifikasikan kebutuhan dependensi--adalah
+langkah paling maju dari kebanyakan perkakas vendor Go, dan menggabungkan ke
+Dep itu sendiri juga merupakan tahap yang jelas.
+Saya dengan sepenuh hati mendukung adopsi Dep, terutama untuk membantu
+pengembang supaya terbiasa berpikir tentang versi paket Go, baik untuk kode
+mereka sendiri dan bagi dependensinya.
+Sementara Dep tampak jelas membawa kita ke arah yang benar, saya memiliki
+kekhawatiran tentang detail kompleksitas di belakangnya.
+Saya secara khusus khawatir tentang tidak adanya dukungan untuk pembaruan kode
+parsial pada Dep untuk program yang besar.
+Selama tahun 2017, saya berbicara dengan banyak orang, termasuk Sam Boyer dan
+kelompok kerja manajemen paket lainnya, namun tidak ada dari kita yang dapat
+melihat cara untuk mengurangi kompleksitas.
+(Saya menemukan banyak pendekatan yang ditambahkan ke Dep.)
+Mendekati akhir tahun, tampaknya solusi SAT dan pembangunan yang tidak
+memuaskan mungkin hal yang terbaik yang dapat kita lakukan.
+
+Pada pertengahan November, mencoba sekali lagi menyelesaikan bagaimana supaya
+Dep dapat mendukung pembaruan kode parsial, saya menyadari bahwa saran lama
+kita tentang kompatibilitas impor mengimplikasikan versi impor semantik.
+Hal ini tampak seperti solusi yang nyata.
+Saya menulis draf pertama yang menjadi artikel
+https://research.swtch.com/vgo-import[versi impor semantik],
+dengan kesimpulan menyarankan supaya Dep mengadopsi konvensi tersebut.
+Saya mengirim draf tersebut ke orang-orang yang telah berbicara dengan saya
+sebelumnya, dan mendapatkan respons yang sangat kuat: semua orang menyukainya
+atau membencinya.
+Saya menyadari bahwa saya perlu menjelaskan lebih lanjut tentang implikasi
+dari versi impor semantik sebelum menyebarkan ide tersebut lebih luas, dan
+saya lakukan itu.
+
+Pada pertengahan Desember, saya menemukan bahwa kompatibilitas impor dan versi
+impor semantik keduanya membolehkan memotong pemilihan versi menjadi
+https://research.swtch.com/vgo-mvs[pemilihan versi minimum].
+Saya menulis implementasi dasar untuk memastikan apakah saya benar-benar
+paham, saya habiskan beberapa waktu untuk mempelajari teori di balik kenapa ia
+begitu sederhana, dan saya tulis sebuah draf artikel yang menjelaskan hal
+tersebut.
+Walaupun begitu, saya masih tidak yakin pendekatan tersebut akan berguna bagi
+perkakas seperti Dep.
+Cukup jelas bahwa sebuah prototipe diperlukan.
+
+Pada bulan Januari 2018, saya mulai mengerjakan sebuah perintah `go` sederhana
+yang mengimplementasikan versi impor semantik dan pemilihan versi minimum.
+Beberapa pengujian sederhana bekerja dengan baik.
+Mendekati akhir bulan, program saya dapat membangun Dep, sebuah program yang
+dibuat dari banyak versi paket-paket.
+Program saya tersebut masih belum memiliki antarmuka baris-perintah--walaupun
+ia bisa membangun Dep namun dengan kode yang menggunakan beberapa
+konstanta--tetapi pendekatan tersebut sangat memungkinkan.
+
+Saya habiskan tiga minggu awal Februari membuat program tersebut menjadi
+sebuah program `go` terpisah, `vgo`;
+menulis draf dari
+https://research.swtch.com/vgo[seri blog memperkenalkan `vgo`];
+dan mendiskusikannya dengan Sam Boyer, kelompok kerja manajemen paket, dan
+tim Go.
+Dan kemudian saya habiskan seminggu terakhir Februari berbagi tentang `vgo`
+dan gagasan-gagasan di baliknya dengan seluruh komunitas Go.
+
+Sebagai tambahan dari ide inti dari kompatibilitas impor, versi impor
+semantik, dan pemilihan versi minimum, prototipe `vgo` memperkenalkan sejumlah
+perubahan kecil yang signifikan yang dimotivasi oleh delapan tahun pengalaman
+dengan `goinstall` dan `go get`: konsep baru dari sebuah
+https://research.swtch.com/vgo-module[Go modul],
+yang merupakan kumpulan paket-paket dengan versi sebagai sebuah unit
+tersendiri;
+https://research.swtch.com/vgo-repro[pembangunan yang dapat diverifikasi dan
+pasti]; dan
+https://research.swtch.com/vgo-cmd[perintah `go` yang mengenal versi],
+membolehkan bekerja di luar $GOPATH dan menghilangkan (kebanyakan) direktori
+vendor.
+
+Hasil dari semua itu adalah sebuah
+https://golang.org/design/24301-versioned-go[proposal Go yang resmi],
+yang saya kirim akhir minggu lalu.
+Walaupun tampak seperti implementasi yang penuh, ia masih prototipe, sebuah
+karya yang harus kita selesaikan bersama.
+Anda bisa mengunduh dan mencoba prototipe vgo lewat
+https://golang.org/x/vgo[golang.org/x/vgo],
+dan Anda bisa membaca
+https://research.swtch.com/vgo-tour[Tur dari Go berversi]
+untuk merasakan seperti apa vgo.
+
+==  Langkah ke depan
+
+Proposal yang saya kirim minggu lalu adalah proposal awal.
+Saya tahu bahwa ada permasalahan yang tim Go dan saya tidak dapat lihat,
+karena para pengguna Go menggunakan bahasa Go dengan cara yang cerdik yang
+tidak kita ketahui.
+Tujuan dari proses umpan-balik proposal adalah supaya kita bekerja bersama
+mengidentifikasi dan menyelesaikan permasalahan tersebut dalam proposal yang
+sekarang, untuk memastikan bahwa implementasi yang final yang diikutkan pada
+rilis Go selanjutnya bekerja dengan benar untuk semua pengembang sebisa
+mungkin.
+Silahkan ajukan permasalahan di
+https://golang.org/issue/24301[isu diskusi proposal].
+Saya akan mencatat
+https://golang.org/issue/24301#issuecomment-371228742[kesimpulan diskusi]
+dan memperbarui
+https://golang.org/issue/24301#issuecomment-371228664[FAQ]
+saat saran-saran bermunculan.
+
+Agar proposal ini sukses, ekosistem Go secara keseluruhan--dan khususnya
+proyek-proyek Go besar sekarang--perlu mengadopsi aturan kompatibilitas impor
+dan versi impor semantik.
+Supaya dapat berjalan dengan mulus, kami juga melakukan sesi umpan-balik lewat
+konferensi video dengan proyek-proyek yang memiliki pertanyaan tentang
+bagaimana menggunakan proposal _versioning_ yang baru dengan basis kode mereka
+atau menerima saran tentang pengalaman mereka.
+Jika Anda tertarik ikut serta dalam sesi seperti itu, silahkan kirim email ke
+Steve Francia di spf@golang.org.
+
+Kami menantikan (akhirnya!) menyediakan komunitas Go sebuah jawaban resmi
+terhadap pertanyaan bagaimana menggunakan versi paket pada `go get`.
+Terima kasih untuk semua orang yang telah membantu kita sampai sekarang, dan
+kepada semua orang yang akan membantu kita maju di masa depan.
+Kami berharap, dengan bantuan Anda, kita dapat membuat sesuatu yang disukai
+oleh pengembang Go.