Versi semantik ditulis dalam bentuk MAJOR.MINOR.PATCH, dengan:
Tambahan label dan versi sebelum rilis atau info tambahan tersedia sebagai ekstensi dari format MAJOR.MINOR.PATCH.
Dalam pengembangan perangkat lunak, sering terjadi permasalahan “dependency hell”. Semakin besar sistem yang dibuat dan semakin banyak modul yang digunakan sistem kita, semakin sering permasalahan ini akan terjadi.
Dalam sistem yang saling terkait, merilis versi baru dari sebuah modul bisa menjadi mimpi buruk. Jika spesifikasi dependensi sistem terlalu ketat, bisa jadi sistem kita tidak bisa dikembangkan lagi. Jika spesifikasi dependensi sistem terlalu bebas, semakin sulit untuk mengatur versi mana yang bisa digunakan dengan versi yang lain. Situasi inilah yang disebut dengan “dependency hell”.
Sebagai solusi permasalahan ini, saya ajukan sebuah standar yang bisa digunakan sebagai dasar untuk menentukan bagaimana cara menentukan versi, dan bagaimana cara menaikkan angka-angka di versi tersebut. Aturan ini hanyalah dasar, dan tidak untuk membatasi standar versi yang sebelumnya sudah digunakan.
Supaya standar ini bisa bermanfaat, pertama kalian harus menentukan API publik, titik dimana kalian mulai menggunakan standar ini. Setelah ditentukan, setiap rilis versi bisa kalian komunikasikan dengan dokumentasi, dan secara langsung melalui angka versi tersebut. Pembetulan bug menaikkan angka patch, penambahan fitur menaikkan angka minor, perubahan yang membuat versi lama tidak bisa digunakan menaikkan angka major.
Standar ini bernama “Pemberian Versi Semantik”, dengan standar ini, setiap orang yang melihat angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut.
Kata HARUS, TIDAK BOLEH, DIBUTUHKAN, SEHARUSNYA, JANGAN SAMPAI, SEBAIKNYA, SEBAIKNYA TIDAK, DIREKOMENDASIKAN, BISA, dan OPSIONAL di dokumen ini sesuai dengan RFC 2119.
Perangkat lunak dengan Versi Semantik harus menentukan API public. Bisa dijelaskan dengan kode, atau ditulis di dokumentasi, ditulis dengan jelas dan akurat.
Versi HARUS ditulis dalam bentuk X.Y.Z, dengan X, Y, Z bilangan bulat positif, dan TIDAK BOLEH didahului angka 0 (contoh 01.02.03). X adalah versi MAJOR, Y adalah minor, dan Z adalah patch.
Setelah versi dirilis, isi dari versi tersebut TIDAK BOLEH dirubah. Setiap perubahan HARUS merilis versi baru.
Versi major 0 (0.y.z) adalah untuk pengembangan awal, saat banyak perubahan bisa terjadi. API publik dianggap tidak stabil di versi ini.
Versi 1.0.0 adalah titik awal API publik, setiap versi baru ditulis berdasarkan versi ini.
| Versi patch Z (x.y.Z | x > 0) HARUS dinaikkan jika ada perbaikan bug tanpa menambah fitur. |
Versi minor Y (x.Y.z | x > 0) HARUS dinaikkan jika ada fitur baru, atau ada fitur lama yang yang sudah usang. Versi ini BISA dinaikkan jika ada tambahan fungsionalitas substansial atau terjadi peningkatan. Versi ini BISA diubah bersama dengan versi patch. Versi patch HARUS dikembalikan ke angka 0 jika versi minor dinaikkan.
Versi major X (X.y.z | X > 0) HARUS dinaikkan jika ada perubahan yang membuat versi baru tidak kompatibel dengan versi lama, seperti menghapus fitur lama, menambah fitur baru yang tidak bisa digunakan di versi lama, BISA diubah bersama dengan versi patch dan minor, jika versi major dinaikkan, maka versi minor dan patch harus dikembalikan ke angka 0.
Versi sebelum rilis BISA ditulis dengan menambahkan garis dan bisa dipisah dengan titik tepat setelah versi patch. Versi sebelum rilis HARUS ditulis dengan huruf ASCII alfanumerik dan garis [0-9A-Za-z], TIDAK BOLEH kosong, dan angka TIDAK BOLEH didahului dengan angka 0. Versi sebelum rilis dianggap tidak stabil dan dikesampingkan jika ada versi yang stabil. Contoh: 1.0.0-alpha, 2.3.1-beta.
Build Metadata BISA ditulis setelah versi sebelum rilis didahului dengan tanda tambah dan bisa dipisah dengan titik. Build Metadata HARUS ditulis dengan huruf ASCII alfanumerik dan garis [0-9A-Za-z]. Build Metadata TIDAK BOLEH kosong. Build Metadata merupakan ID dari hasil build, dan dikesampingkan jika ada versi sebelum rilis atau versi yang lebih stabil. Contoh: 1.0.0-alpha+1, 1.5.2+3312
Versi Semantik bukanlah ide baru yang revolusioner, faktanya, kalian mungkin sudah menggunakan standar ini, hanya saja tidak terlalu ketat. Masalahnya, jika tidak diatur dengan ketat akan terjadi permasalah seperti “dependency hell” di atas. Tanpa ada standar, maka pengatur kebutuhan sistem seperti NPM, Composer, tidak akan bisa bekerja dengan baik. Dengan adanya standar ini, bisa lebih mudah dalam mengatur versi dan pengatur kebutuhan sistem bisa bekerja lebih baik.
Contoh sederhana berikut ini menunjukkan manfaat Pemberian Versi Semantik untuk menghilangkan “dependency hell”. Misalkan ada sebuah modul bernama “MobilPemadamKebakaran”. Modul “MobilPemadamKebakaran” membutuhkan modul lain bernama “Tangga”. Pada waktu “MobilPemadamKebakaran” dibuat, “Tangga” memiliki versi 3.1.0. Dengan menggunakan Pemberian Versi Semantik, “MobilPemadamKebakaran” bisa dengan yakin menggunakan modul “Tangga” selama modul tersebut mempunyai versi antara 3.1.0 sampai dengan sebelum versi 4.0.0.
Pemberian Versi Semantik adalah aturan baku yang bisa diikuti atau tidak diikuti, dan tugas dari standar pemberian versi semantik hanyalah untuk membantu supaya pemberian versi bisa lebih jelas.
Jika menurut kalian aturan baku ini bagus, kalian bisa mulai menggunakan pemberian versi semantik. Tautkan situs ini dalam README kalian supaya orang lain bisa tahu mengenai aturan ini dan mulai menggunakannya juga.
Paling mudah adalah memulai dengan versi 0.1.0.
Ketika sistem yang dikembangkan sudah stabil dan digunakan dalam lingkungan produksi, kalian bisa mulai menentukannya dengan versi 1.0.0.
Versi 0.1.0 adalah tempat dimana banyak perubahan terjadi, jadi standar ini tidak mencegah perkembangan yang cepat.
Ini lebih ke permasalahan pengembangan, jika pengembangan dilakukan dengan seksama, maka seharusnya tidak terjadi perubahan yang terlalu signifikan dalam waktu yang cepat.
Sudah tanggung jawab pengembang untuk memastikan sistemnya bisa digunakan dengan baik dan mudah. Pemberian Versi Semantik hanya memandu orang untuk konsisten dan bisa bekerja sama dengan baik.
Langsung ganti perubahan tersebut dan kembalikan supaya masih bisa digunakan versi lama dan naikkan versi minor.
Seharusnya tidak berpengaruh, karena kebutuhan sistem anda sudah memiliki versi sendiri, dan API publik anda seharusnya berfungsi sebaga jembatan atau hanya sekedar memanfaatkan fitur dari sistem-sistem luar tersebut.
Gunakan kebijakan terbaik kalian, jika ada pengguna sistem kalian yang sangat besar, maka lebih baik segera rilis versi major, meskipun perubahannya tidak begitu mencolok. Dengan ini pengguna sistem bisa lebih tahu tentang perubahan yang ada di sistem. Ingat, Versi Semantik hanyalah standar sebagai media untuk memberitahu bahwa sistem yang ada sudah berubah dengan batasan-batasan tertentu.
Fitur yang usang bisa kalian jelaskan di dokumentasi sehingga pengguna sistem bisa sedikit demi sedikit beradaptasi dengan fitur yang usang setiap ada perubahan versi minor, jika kalian sudah siap menghapus fitur yang usang, hapus fitur tersebut di perubahan versi major.
Tidak ada, tapi sebaiknya gunakan saja secukupnya. Versi sepanjang 255 terlalu banyak dan membuat pengguna kesulitan untuk membacanya.
Spesifikasi Versi Semantik dibuat oleh Tom Preston-Werner, pembuat Gravatars dan cofounder dari GitHub.
Translasi Bahasa Indonesia ditulis oleh Aditya Purwa dan dikoreksi oleh Christian B. Wibowo.
Untuk saran dan kritik, buka issue di GitHub.