Pride Versioning Memicu Perdebatan Tentang Alternatif Penomoran Rilis Software Selain Semantic Versioning

Tim Komunitas BigGo
Pride Versioning Memicu Perdebatan Tentang Alternatif Penomoran Rilis Software Selain Semantic Versioning

Komunitas pengembangan software sedang ramai membicarakan Pride Versioning, sebuah pendekatan humor terhadap penomoran versi software yang menggantikan semantic versioning tradisional dengan pendekatan yang lebih jujur secara emosional. Dibuat oleh Niki Tonsky, sistem alternatif ini menggunakan format PROUD.DEFAULT.SHAME alih-alih struktur major.minor.patch yang konvensional.

Perbandingan Format Pride Versioning

Sistem Versioning Format Contoh Karakteristik Utama
Pride Versioning PROUD.DEFAULT.SHAME 2.7.123 Peningkatan berbasis emosi
Semantic Versioning MAJOR.MINOR.PATCH 2.7.123 Berbasis dampak teknis
Calendar Versioning YYYY.MM.DD 2020.12.07 Rilis berbasis tanggal
OpenSSL System MAJOR.MINOR.LETTER 1.1.1a Aturan kompatibilitas khusus
Gambar ini mengilustrasikan sistem Pride Versioning, menyoroti bagaimana nomor versi dapat mencerminkan keterlibatan emosional dengan perubahan pengembangan
Gambar ini mengilustrasikan sistem Pride Versioning, menyoroti bagaimana nomor versi dapat mencerminkan keterlibatan emosional dengan perubahan pengembangan

Komunitas Mengungkap Praktik Versioning Dunia Nyata yang Unik

Konsep Pride Versioning telah mendorong para developer untuk berbagi contoh skema versioning yang tidak konvensional yang sudah digunakan oleh proyek-proyek besar. Kebijakan versioning OpenSSL menonjol sebagai sesuatu yang sangat tidak biasa untuk software infrastruktur yang begitu kritis. Sistem mereka menggunakan rilis major untuk perubahan yang merusak kompatibilitas, rilis minor untuk penambahan fitur yang mempertahankan kompatibilitas biner, dan rilis huruf khusus untuk perbaikan bug dan keamanan. Pendekatan ini berbeda signifikan dari semantic versioning standar, namun melayani salah satu bagian software paling sensitif keamanan di dunia komputasi.

Sejarah versioning Ruby memberikan studi kasus menarik lainnya. Bahasa pemrograman ini sebelumnya mengikuti apa yang mereka sebut Semantic Versioning, tetapi dengan sentuhan unik - versi minor dirilis setiap Hari Natal di Jepang, terlepas dari kompatibilitas API. Pendekatan berbasis kalender ini memprioritaskan waktu rilis yang dapat diprediksi daripada pertimbangan teknis, meskipun Ruby sejak itu telah bergerak lebih dekat ke praktik semantic versioning tradisional.

Pendekatan Versioning Alternatif Mendapat Perhatian

Diskusi ini juga telah menyoroti calendar versioning, yang kadang disebut Gregorian versioning oleh anggota komunitas, sebagai alternatif praktis untuk semantic versioning. Pendekatan ini menggunakan tanggal dalam nomor versi, membuat jelas secara langsung kapan software terakhir kali diperbarui. Versioning paket Ubuntu mencontohkan metode ini, membantu pengguna dengan cepat mengidentifikasi apakah proyek sedang aktif dipelihara atau telah ditinggalkan.

Ini lebih masuk akal daripada yang terlihat. semver adalah kebohongan karena setiap perubahan adalah perubahan yang merusak

Sentimen ini mencerminkan skeptisisme yang berkembang tentang efektivitas semantic versioning dalam praktik, merujuk pada Hukum Hyrum - prinsip bahwa dengan cukup banyak pengguna, setiap perilaku yang dapat diamati menjadi bagian dari API.

Aturan Versioning Pride

  • Versi PROUD: Tingkatkan ketika membuat perubahan yang benar-benar Anda banggakan
  • Versi DEFAULT: Tingkatkan untuk rilis yang biasa-biasa saja
  • Versi SHAME: Tingkatkan ketika memperbaiki bug yang memalukan
  • Aturan reset: Ketika meningkatkan versi PROUD, reset nomor lain ke 0 (contoh: 1.2.3 → 2.0.0)
  • Ekstensi: Label pre-release dan build metadata tersedia

Reality Check untuk Semantik Nomor Versi

Meskipun Pride Versioning dimulai sebagai konsep humor, hal ini telah beresonansi dengan para developer yang mengenali realitas emosional di balik rilis software. Diskusi komunitas mengungkapkan bahwa banyak developer sudah secara informal mengkategorikan rilis mereka berdasarkan tingkat kepercayaan daripada dampak teknis saja. Beberapa developer mencatat bahwa digit versi marketing harus ditambahkan sebagai nomor pertama, mengakui bagaimana pertimbangan bisnis sering mengalahkan logika versioning teknis.

Percakapan ini pada akhirnya menyoroti tantangan berkelanjutan dalam mengomunikasikan perubahan software secara efektif kepada pengguna sambil menyeimbangkan akurasi teknis dengan kebutuhan praktis.

Referensi: Pride Versioning 0.3.0