Saya sedang menjelaskan sistem pembangunan yang diusulkan (Gradle / Artifactory / Jenkins / Chef) kepada salah satu arsitek senior kami, dan dia berkomentar kepada saya bahwa saya agak tidak setuju, tetapi saya tidak cukup berpengalaman untuk benar-benar mempertimbangkannya.
Proyek ini membangun perpustakaan Java (JAR) sebagai artefak untuk digunakan kembali oleh tim lain. Untuk versi, saya ingin menggunakan pendekatan semantik:
<major>.<minor>.<patch>
Di mana patch
menunjukkan perbaikan bug / darurat, minor
menunjukkan rilis yang kompatibel ke belakang, dan major
menunjukkan baik refactoring besar-besaran dari API dan / atau perubahan yang tidak kompatibel ke belakang.
Sejauh pengiriman berlangsung di sini adalah apa yang saya inginkan: seorang pengembang melakukan beberapa kode; ini memicu build ke lingkungan QA / TEST. Beberapa tes dijalankan (beberapa otomatis, beberapa manual). Jika semua tes lulus, maka bangunan produksi menerbitkan JAR ke dalam repo kami. Pada titik ini JAR harus diversi dengan benar, dan pemikiran saya adalah untuk menggunakan build.number
yang secara otomatis dihasilkan dan disediakan oleh alat CI kami untuk bertindak sebagai nomor tambalan.
Jadi, versi sebenarnya adalah:
<major>.<minor>.<build.number>
Sekali lagi, di mana build.number
disediakan oleh alat CI.
Arsitek menolak ini, mengatakan bahwa menggunakan nomor build CI adalah "penyalahgunaan" versi semantik.
Pertanyaan saya adalah: apakah ini benar, dan jika demikian, mengapa? Dan jika tidak, mengapa tidak?