Pendahuluan


Penasaran dengan versi sebuah aplikasi ?

Baik itu aplikasi Game, Ecommerce, Banking di Android, aplikasi web, ataupun aplikasi software lainnya berupa library atau framework ?

Misalnya ketika membuka sebuah aplikasi Android, misalnya aplikasi L**ing M**d*ri untuk kebutuhan internet banking kita, ataupun aplikasi game M*bil* Le*ends, atau Cl**h of Cl*n yang membuat beberapa orang kecanduan.

Ketika baru membuka aplikasinya, kita bisa saja diminta untuk mengupdate versi terbarunya agar bisa menggunakan fitur-fitur yang lebih bagus dan lebih baru.

Biasanya akan ditambahkan kata-kata “Silahkan update ke versi X.Y.Z untuk menikmati pengalaman yang lebih baik”.

Dari informasi tersebut kita bisa tahu bahwa X.Y.Z adalah versi terbaru dari aplikasi tersebut.

Misalnya, versi dari aplikasi Cl**h of Cl*n sekarang ini adalah 14.426.3

Sementara, versi dari L**ing M*nd*ri adalah 1.0.2


Apa semua aplikasi memakai versi X.Y.Z begitu ?

Sebenarnya setiap aplikasi berhak memakai penamaan versi aplikasi nya sendiri, tidak harus dalam bentuk 3 bagian angka berbeda dipisahkan oleh tanda titik.

Misalnya kalau kita lihat di versioning library Spring Cloud, maka penamaannya sekarang memakai format YYYY.MINOR.MICRO dimana YYYY merupakan tahun, MINOR merupakan nomor sekuensial, dan MICRO merupakan nomor sequensial selanjutnya.

Contohnya : Spring Cloud 2021.0.1

Bahkan sebelumnya lagi, sebelum tahun 2020, penamaannya memakai penamaan kata-kata dalam urutan Abjad, seperti :

  • Angel
  • Brixton
  • Dalston
  • dst

Bisa di lihat di sini

Atau ada juga yang memakai penamaan versi 4 angka dipisahkan dengan tanda titik.

Seperti yang kita lihat di penamaan versi di aplikasi game di Android, M*bil* Le*ends.

Versinya sekarang adalah 1.6.58.7191.

Waaw sangat banyak sekali urutannya.

Ok2.., jadi bukan hanya versioning dengan cara X.Y.Z saja ya ..

Salah satunya memang dengan format X.Y.Z tersebut.

Dinamakan Semantic Versioning.


Kenapa ada versi Semantic Versioning ini ?

Semantic Versioning ini awalnya merupakan usulan penamaan versi untuk Public API.

Public API maksudnya adalah aplikasi/library yang kita buatkan versinya ini dipakai secara umum/publik, contohnya library yang kita bisa ambil dari Maven Central kalau kita pakai maven, npm library kalau pakai node, dll.

Oleh karena itu, Semantic Versioning ini terkenal dan menjadi standard di komunitas Open Source.

Jadi kalau aplikasi kita, atau library kita tidak dipakai secara umum/public, maka Semantic Versioning ini sebenarnya tidak berguna.


Apa sih sebenarnya gunanya ?

Semantik artinya ilmu tentang makna.

Semantics, also called semiotics, semology, or semasiology, the philosophical and scientific study of meaning in natural and artificial languages.

dari Britannica

kalau kita terjemahkan bebas.

Semantic Versioning adalah penamaan versi yang punya makna.

Lho, apa penamaan memakai format versi yang lain tidak mempunyai makna ?

Tentu saja ada, tetapi di Semantic Versioning ini ada makna yang lebih mendalam yang diformulasikan dalam aturan-aturan tertentu.

Mulai deh lebay..

Eh seriuusaan..Semantic Versioning memang ingin memberikan makna di setiap penamaan versi release software dengan aturan tertentu.

Mau lihat aturannya, bisa di official web nya di sini.

Kalau tanya gunanya , maka gunanya yang paling utama adalah untuk komunikasi antara developer library/public API, yang satu sama lain yang saling menggunakan library.

Bingung kaan..! ok lanjut dulu .


Apa yang mau diselesaikan oleh Semantic Versioning ini ?

Aplikasi yang kita buat sekarang hampir selalu tergantung dari library yang bermacam-macam. Mungkin bisa puluhan atau ratusan library yang kita gunakan di aplikasi kita.

Tiap library ini punya lagi dependency ke library lain yang belum tentu kompatibel kalau diupgrade versinya.

Istilahnya “Dependency Hell”.

Misalnya aplikasi kita tergantung dan menggunakan library A dan library B yang tersedia secara OpenSource.

Ketika kita ingin mengupdate aplikasi kita dengan library terbaru dari library A dan library B, bagaimana untuk memastikan secara cepat bahwa library A dan library B tetap kompatibel dengan aplikasi kita ?

Sebelumnya library A mempunyai versi 2.3.1-RELEASE, dan versi terbarunya 3.2.0-RELEASE. Apakah kompatibel dengan aplikasi kita yang lama ?

Sebelumnya library B mempunyai versi 2.3.1-RELEASE, dan versi terbarunya 2.12.10-RELEASE. Apakah kompatibel dengan aplikasi kita yang lama ?

Kalau cuma 2 library saja mungkin tidak membuat pusing, akan tetapi kalau puluhan bahkan ratusan library yang perlu kita cek, maka kita perlu mengecek satu persatu library ketergantungan kita tersebut.

Adakah cara yang lebih baik ?

Semantic Versioning mengajukan usul untuk masalah diatas dengan cara memberikan makna di setiap penamaan versi dari library yang kita release untuk umum/publik.


Bagaimana usulnya itu ?

Pakai penamaan MAJOR.MINOR.PATCH, dimana :

  • menambahkan angka MAJOR jika release versi ini tidak kompatibel dengan versi sebelumnya.
  • menambahkan angka MINOR jika release versi ini menambahkan fitur baru dan tetap kompatibel dengan versi sebelumnya.
  • menambahkan angka PATCH jika release versi ini perbaikan bug dan tetap kompatibel dengan versi sebelumnya.

Setelah versi MAJOR.MINOR.PATCH ini, maka bisa saja ditambahkan label untuk penanda tambahan.

Misalnya :

  • -RELEASE
  • -RC (Release Candidate)
  • -GA (General Availibility)
  • -EA (Early Access)
  • -M (Milestone)
  • -beta
  • dll

Tetapi tetap yang jadi patokan utamanya adalah penamaan MAJOR.MINOR.PATCH nya.

Contoh kasus :

versi sekarang 1.2.2-RELEASE

  • Ketika kita mengubah fungsi dan parameter public API, maka tidak kompatibel lagi dengan versi sebelumnya. Maka versinya bisa dinaikkan ke 2.0.0-RELEASE nantinya.
  • Ketika kita hanya menambah sebuah public API baru, dan tentunya tetap kompatibel dengan versi sebelumnya. Maka versinya bisa dinaikkan ke 1.3.0-RELEASE nantinya.
  • Ketika kita hanya melakukan bug fixing tanpa mengubah public API nya, maka versinya bisa dinaikkan ke 1.2.3-RELEASE nantinya.

Apa efeknya kalau kita menggunakan pendekatan Semantic Versioning diatas?

Lagi-lagi gunanya adalah untuk komunikasi antara Software Engineer/Team yang saling menggunakan library.

Kembali ke kasus aplikasi diatas yang menggunakan library A dan library B.

Ketika kita melihat bahwa library A hanya berubah di bagian MINOR saja, maka kita bisa dengan cepat menyimpulkan bahwa library tersebut masih kompatibel dengan aplikasi kita.

Tetapi ketika kita melihat bahwa library A berubah di bagian MAJOR, maka kita harus siap-siap untuk bisa memperbaiki bagian yang tidak kompatibel dengan aplikasi kita.

Bahkan di beberapa package/library manager, seperti npm, kita bisa menentukan range versi library dependency yang kita ingin otomatis diupdate tanpa dikhawatirkan library tersebut tidak kompatibel dengan aplikasi kita.