diff --git a/_config.yml b/_config.yml index 57c8b5ae..c5384d2b 100644 --- a/_config.yml +++ b/_config.yml @@ -7,7 +7,7 @@ languages: uk: українська es: español it: italiano - id: bahasa Indonesia + id: Bahasa Indonesia pt-BR: português brasileiro zh-TW: 繁體中文 zh-CN: 简体中文 diff --git a/lang/ar/index.md b/lang/ar/index.md index 2ccb3860..82912b06 100644 --- a/lang/ar/index.md +++ b/lang/ar/index.md @@ -123,7 +123,7 @@ Preston-Werner](http://tom.preston-werner.com), مُبتكر خدمة Gravatars راجعه ودققه لغويا: [يوغرطة بن علي](https://twitter.com/djug). لديك اقتراح؟ يُرجى [فتح "خطب" على -GitHub](https://github.com/mojombo/semver/issues). +GitHub](https://github.com/semver/semver/issues). لديك مُلاحظات/مُساهمات حول الترجمة؟ افتح خطبًا [من هنا](https://github.com/01walid/semver.org/issues). diff --git a/lang/ar/spec/v2.0.0.md b/lang/ar/spec/v2.0.0.md index 2ccb3860..82912b06 100644 --- a/lang/ar/spec/v2.0.0.md +++ b/lang/ar/spec/v2.0.0.md @@ -123,7 +123,7 @@ Preston-Werner](http://tom.preston-werner.com), مُبتكر خدمة Gravatars راجعه ودققه لغويا: [يوغرطة بن علي](https://twitter.com/djug). لديك اقتراح؟ يُرجى [فتح "خطب" على -GitHub](https://github.com/mojombo/semver/issues). +GitHub](https://github.com/semver/semver/issues). لديك مُلاحظات/مُساهمات حول الترجمة؟ افتح خطبًا [من هنا](https://github.com/01walid/semver.org/issues). diff --git a/lang/ca/index.md b/lang/ca/index.md index c59c80d4..0732cd87 100644 --- a/lang/ca/index.md +++ b/lang/ca/index.md @@ -276,7 +276,7 @@ Traducció d'aquest document a càrrec de: - [Jordi Sanfeliu](https://github.com/mikaku) Si voleu deixar comentaris, si us plau [obre un tiquet a -GitHub](https://github.com/mojombo/semver/issues). +GitHub](https://github.com/semver/semver/issues). Llicència --------- diff --git a/lang/ca/spec/v2.0.0.md b/lang/ca/spec/v2.0.0.md index 3819c835..c8cf1bb8 100644 --- a/lang/ca/spec/v2.0.0.md +++ b/lang/ca/spec/v2.0.0.md @@ -276,7 +276,7 @@ Traducció d'aquest document a càrrec de: - [Jordi Sanfeliu](https://github.com/mikaku) Si voleu deixar comentaris, si us plau [obre un tiquet a -GitHub] (https://github.com/mojombo/semver/issues). +GitHub] (https://github.com/semver/semver/issues). Llicència --------- diff --git a/lang/cs/index.md b/lang/cs/index.md index 27cd3b3a..dc46e643 100644 --- a/lang/cs/index.md +++ b/lang/cs/index.md @@ -123,7 +123,7 @@ Autorem Specifikace sémantického verzování je [Tom Preston-Werner](http://tom.preston-werner.com), autor projektu Gravatar a spolu-zakladatel projektu Github. Pokud chcete zanechat zpětnou vazbu, prosím -[přes GitHub](https://github.com/mojombo/semver/issues). +[přes GitHub](https://github.com/semver/semver/issues). ### Český překlad diff --git a/lang/cs/spec/v2.0.0.md b/lang/cs/spec/v2.0.0.md index cf3644c0..8d0f12ec 100644 --- a/lang/cs/spec/v2.0.0.md +++ b/lang/cs/spec/v2.0.0.md @@ -121,7 +121,7 @@ Autorem Specifikace sémantického verzování je [Tom Preston-Werner](http://tom.preston-werner.com), autor projektu Gravatar a spolu-zakladatel projektu Github. Pokud chcete zanechat zpětnou vazbu, prosím -[přes GitHub](https://github.com/mojombo/semver/issues). +[přes GitHub](https://github.com/semver/semver/issues). ### Český překlad diff --git a/lang/de/index.md b/lang/de/index.md index 86fcf05e..f3a4400a 100644 --- a/lang/de/index.md +++ b/lang/de/index.md @@ -180,7 +180,7 @@ Nein, aber sei vernünftig. Zum Beispiel, wäre ein 255 Zeichen langer Version S Die *Semantic Versioning* Spezifikation wurde von [Tom Preston-Werner](http://tom.preston-werner.com), Erfinder von Gravatars und Mitbegründer von GitHub, erstellt. -Für Feedback, [eröffne bitte ein Issue auf GitHub](https://github.com/mojombo/semver/issues). +Für Feedback, [eröffne bitte ein Issue auf GitHub](https://github.com/semver/semver/issues). Lizenz ------ diff --git a/lang/de/spec/v2.0.0.md b/lang/de/spec/v2.0.0.md index 49eb1195..5d174b2d 100644 --- a/lang/de/spec/v2.0.0.md +++ b/lang/de/spec/v2.0.0.md @@ -180,7 +180,7 @@ Nein, aber sei vernünftig. Zum Beispiel, wäre ein 255 Zeichen langer Version S Die *Semantic Versioning* Spezifikation wurde von [Tom Preston-Werner](http://tom.preston-werner.com), Erfinder von Gravatars und Mitbegründer von GitHub, erstellt. -Für Feedback, [eröffne bitte ein Issue auf GitHub](https://github.com/mojombo/semver/issues). +Für Feedback, [eröffne bitte ein Issue auf GitHub](https://github.com/semver/semver/issues). Lizenz ------ diff --git a/lang/fa/index.md b/lang/fa/index.md index 3fa74dec..2e2db00c 100644 --- a/lang/fa/index.md +++ b/lang/fa/index.md @@ -117,7 +117,7 @@ language_dir: rtl بنیان‌گذار GitHub. اگر مایل به ارائهٔ بازخورد خود هستید، لطفاً یک مورد در بخش issue سایت GitHub باز کنید. - [open an issue on GitHub](https://github.com/mojombo/semver/issues). + [open an issue on GitHub](https://github.com/semver/semver/issues). مترجم بخش فارسی : مجید حاجیان [Majid Hajian](https://www.majidhajian.com) ویراستار: فرزاد قانعی [Farzad Ghanei]( http://www.ghanei.net) diff --git a/lang/fa/spec/v2.0.0.md b/lang/fa/spec/v2.0.0.md index 3fa74dec..2e2db00c 100644 --- a/lang/fa/spec/v2.0.0.md +++ b/lang/fa/spec/v2.0.0.md @@ -117,7 +117,7 @@ language_dir: rtl بنیان‌گذار GitHub. اگر مایل به ارائهٔ بازخورد خود هستید، لطفاً یک مورد در بخش issue سایت GitHub باز کنید. - [open an issue on GitHub](https://github.com/mojombo/semver/issues). + [open an issue on GitHub](https://github.com/semver/semver/issues). مترجم بخش فارسی : مجید حاجیان [Majid Hajian](https://www.majidhajian.com) ویراستار: فرزاد قانعی [Farzad Ghanei]( http://www.ghanei.net) diff --git a/lang/fr/index.md b/lang/fr/index.md index e16d67c0..2e56c175 100644 --- a/lang/fr/index.md +++ b/lang/fr/index.md @@ -277,7 +277,7 @@ Preston-Werner](http://tom.preston-werner.com), inventeur de Gravatars et cofondateur de GitHub. Si vous souhaitez laisser des commentaires, veuillez [ouvrir un ticket sur -GitHub](https://github.com/mojombo/semver/issues). +GitHub](https://github.com/semver/semver/issues). Licence ------- diff --git a/lang/fr/spec/v2.0.0.md b/lang/fr/spec/v2.0.0.md index 89d2056a..fe92049c 100644 --- a/lang/fr/spec/v2.0.0.md +++ b/lang/fr/spec/v2.0.0.md @@ -277,7 +277,7 @@ Preston-Werner](http://tom.preston-werner.com), inventeur de Gravatars et cofondateur de GitHub. Si vous souhaitez laisser des commentaires, veuillez [ouvrir un ticket sur -GitHub](https://github.com/mojombo/semver/issues). +GitHub](https://github.com/semver/semver/issues). Licence ------- diff --git a/lang/he/index.md b/lang/he/index.md index bb3b5c1b..480e5eb5 100644 --- a/lang/he/index.md +++ b/lang/he/index.md @@ -132,7 +132,7 @@ PCRE, Perl, PHP, R, Python ו-Go). מפרט הגירסאות הסמנטיות נכתב על ידי [טום פרסון-ורנר](http://tom.preston-werner.com) ממציא ה Gravatars וממייסדי GitHub. -אם את/ה רוצה להשאיר משוב, אנא [פתח/י issue ב GitHub](https://github.com/mojombo/semver/issues). +אם את/ה רוצה להשאיר משוב, אנא [פתח/י issue ב GitHub](https://github.com/semver/semver/issues). רישיון ------- diff --git a/lang/he/spec/v2.0.0.md b/lang/he/spec/v2.0.0.md index 028508d5..50a014ab 100644 --- a/lang/he/spec/v2.0.0.md +++ b/lang/he/spec/v2.0.0.md @@ -116,7 +116,7 @@ language_dir: rtl מפרט הגירסאות הסמנטיות נכתב על ידי [טום פרסון-ורנר](http://tom.preston-werner.com) ממציא ה Gravatars וממייסדי GitHub. -אם את/ה רוצה להשאיר משוב, אנא [פתח/י issue ב GitHub](https://github.com/mojombo/semver/issues). +אם את/ה רוצה להשאיר משוב, אנא [פתח/י issue ב GitHub](https://github.com/semver/semver/issues). רישיון ------- diff --git a/lang/hin/index.md b/lang/hin/index.md index f7d62458..8558da13 100644 --- a/lang/hin/index.md +++ b/lang/hin/index.md @@ -114,7 +114,7 @@ language: hin अर्थात् संस्करण संस्करण विनिर्देशन [ट्रा प्रेस्टन-वर्नर](http://tom.preston-werner.com) , ग्रेवाटर के आविष्कारक और गिटहब के कोफाउंडर द्वारा लिखा गया है। -अगर आप फीडबैक छोड़ना चाहते हैं, तो कृपया [गिटहब पर एक समस्या खोलें](https://github.com/mojombo/semver/issues)। +अगर आप फीडबैक छोड़ना चाहते हैं, तो कृपया [गिटहब पर एक समस्या खोलें](https://github.com/semver/semver/issues)। लाइसेंस ----- diff --git a/lang/hin/spec/v2.0.0.md b/lang/hin/spec/v2.0.0.md index af5b1c04..b9e4d1b0 100644 --- a/lang/hin/spec/v2.0.0.md +++ b/lang/hin/spec/v2.0.0.md @@ -112,7 +112,7 @@ language: hin अर्थात् संस्करण संस्करण विनिर्देशन [ट्रा प्रेस्टन-वर्नर](http://tom.preston-werner.com) , ग्रेवाटर के आविष्कारक और गिटहब के कोफाउंडर द्वारा लिखा गया है। -अगर आप फीडबैक छोड़ना चाहते हैं, तो कृपया [गिटहब पर एक समस्या खोलें](https://github.com/mojombo/semver/issues)। +अगर आप फीडबैक छोड़ना चाहते हैं, तो कृपया [गिटहब पर एक समस्या खोलें](https://github.com/semver/semver/issues)। लाइसेंस ----- diff --git a/lang/hr/index.md b/lang/hr/index.md index decf65a1..672695e9 100644 --- a/lang/hr/index.md +++ b/lang/hr/index.md @@ -249,7 +249,7 @@ Preston-Werner](http://tom.preston-werner.com), izumitelj Gravatara i suosnivač GitHuba. Ako želite ostaviti povratne informacije, molimo [otvorite issue na -GitHubu](https://github.com/mojombo/semver/issues). +GitHubu](https://github.com/semver/semver/issues). Licenca ------- diff --git a/lang/hr/spec/v2.0.0.md b/lang/hr/spec/v2.0.0.md index e070266b..cff9f659 100644 --- a/lang/hr/spec/v2.0.0.md +++ b/lang/hr/spec/v2.0.0.md @@ -249,7 +249,7 @@ Preston-Werner](http://tom.preston-werner.com), izumitelj Gravatara i suosnivač GitHuba. Ako želite ostaviti povratne informacije, molimo [otvorite issue na -GitHubu](https://github.com/mojombo/semver/issues). +GitHubu](https://github.com/semver/semver/issues). Licenca ------- diff --git a/lang/hu/index.md b/lang/hu/index.md index fdee921d..8fcf4789 100644 --- a/lang/hu/index.md +++ b/lang/hu/index.md @@ -243,7 +243,7 @@ Infó A Semantic Versioning specifikáció szerzője [Tom Preston-Werner](http://tom.preston-werner.com), a Gravatars feltalálója és a GitHub társalapítója. -Észrevételekért [nyiss egy issue-t a GitHub-on](https://github.com/mojombo/semver/issues). +Észrevételekért [nyiss egy issue-t a GitHub-on](https://github.com/semver/semver/issues). Fordította: [Rebeka Marton](https://github.com/esztermarton) (szerző), diff --git a/lang/hu/spec/v2.0.0.md b/lang/hu/spec/v2.0.0.md index fdee921d..8fcf4789 100644 --- a/lang/hu/spec/v2.0.0.md +++ b/lang/hu/spec/v2.0.0.md @@ -243,7 +243,7 @@ Infó A Semantic Versioning specifikáció szerzője [Tom Preston-Werner](http://tom.preston-werner.com), a Gravatars feltalálója és a GitHub társalapítója. -Észrevételekért [nyiss egy issue-t a GitHub-on](https://github.com/mojombo/semver/issues). +Észrevételekért [nyiss egy issue-t a GitHub-on](https://github.com/semver/semver/issues). Fordította: [Rebeka Marton](https://github.com/esztermarton) (szerző), diff --git a/lang/id/index.md b/lang/id/index.md index de9be344..84b3d3ee 100644 --- a/lang/id/index.md +++ b/lang/id/index.md @@ -1,15 +1,13 @@ --- -title: Versi Semantik 2.0.0 +title: Pemversian Semantik 2.0.0 language: id -redirect_from: /lang/id/ -author: Aditya Purwa --- -Versi Semantik 2.0.0 -============================== +Pemversian Semantik 2.0.0 +========================= Ringkasan -------- +--------- Versi semantik ditulis dalam bentuk MAJOR.MINOR.PATCH, dengan: @@ -21,144 +19,211 @@ Tambahan label dan versi sebelum rilis atau info tambahan tersedia sebagai ekste MAJOR.MINOR.PATCH. Pendahuluan ------------- - -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". +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. -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. +Dalam sistem yang saling terkait, merilis versi baru 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 berasumsi versi mana yang bisa digunakan dengan versi yang lain. *Dependency hell* adalah saat Anda berada pada satu atau dua masalah ini, yang menahan Anda untuk bergerak maju dengan aman dan mudah. -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. +Sebagai solusi permasalahan ini, kami mengusulkan seperangkat aturan dan persayaratan sederhana yang menentukan bagaimana nomor versi diberikan dan bertambah. Aturan-aturan ini didasarkan pada, namun tidak terbatas pada, praktik-praktik yang sudah ada pada perangkat lunak sumber terbuka dan tertutup. Agar sistem ini dapat bekerja, Anda harus mengumumkan API publik terlebih dahulu. Ini dapat terdiri dari dokumentasi atau diberlakukan oleh kode itu sendiri. Apapun itu, API ini harus jelas dan tepat. Setelah Anda mengidentifikasi API publik Anda, Anda mengomunikasikan perubahan pada API tersebut dengan penambahan spesifik pada nomor versi Anda. Pertimbangkan format versi X.Y.Z (Major.Minor.Patch). Perbaikan bug yang tidak memengaruhi API tersebut akan menambah versi *patch*, penambahan/perubahan API yang kompatibel dengan versi sebelumnya akan menambah versi *minor*, dan perubahan API yang tidak kompatibel dengan versi sebelumnya akan menambah versi 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. +Standar ini bernama "Pemversian Semantik". Dengan skema ini, setiap orang yang melihat angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut. -Spesifikasi Versi Semantik (VerSem) ------------------------------------------- +Spesifikasi Pemversian Semantik (SemVer) +---------------------------------------- -Kata HARUS, TIDAK BOLEH, DIBUTUHKAN, SEHARUSNYA, JANGAN SAMPAI, SEBAIKNYA, SEBAIKNYA TIDAK, -DIREKOMENDASIKAN, BISA, dan OPSIONAL di dokumen ini sesuai dengan [RFC 2119](http://tools.ietf.org/html/rfc2119). +Kata/frasa "HARUS" ("MUST"), "TIDAK BOLEH" ("MUST NOT"), "DIBUTUHKAN" ("REQUIRED"), "SEHARUSNYA" ("SHALL"), "JANGAN SAMPAI" ("SHALL NOT"), "SEBAIKNYA" ("SHOULD"), "SEBAIKNYA TIDAK" ("SHOULD NOT"), "DIREKOMENDASIKAN" ("RECOMMENDED"), "BISA" ("MAY") di dokumen ini sesuai dengan [RFC 2119](https://tools.ietf.org/html/rfc2119). -1. Perangkat lunak dengan Versi Semantik harus menentukan API public. Bisa -dijelaskan dengan kode, atau ditulis di dokumentasi, ditulis dengan jelas dan akurat. +1. Perangkat lunak dengan Pemversian Semantik HARUS menentukan API public. Bisa dijelaskan dengan kode, atau ditulis di dokumentasi saja. Apapun itu HARUS ditulis dengan jelas dan akurat. -2. 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. +1. Versi normal HARUS ditulis dalam bentuk X.Y.Z, dengan X, Y, dan Z adalah bilangan bulat nonnegatif, dan TIDAK BOLEH didahului angka 0 (contoh 01.02.03). X adalah versi *major*, Y adalah *minor*, dan Z adalah *patch*. Setiap elemen HARUS bertambah secara numerik dengan kenaikan sebesar satu. Contohnya: 1.9.0 -> 1.10.0 -> 1.11.0 -3. Setelah versi dirilis, isi dari versi tersebut TIDAK BOLEH dirubah. Setiap perubahan HARUS -merilis versi baru. +1. Setelah sebuah paket berversi dirilis, isi dari versi tersebut TIDAK BOLEH diubah. Setiap perubahan HARUS dirilis sebagai versi baru. -4. Versi major 0 (0.y.z) adalah untuk pengembangan awal, saat banyak perubahan bisa terjadi. API publik +1. Versi *major* 0 (0.y.z) adalah untuk pengembangan awal. Apapun BISA bisa berubah kapan saja. API publik SEBAIKNYA dianggap tidak stabil di versi ini. -5. Versi 1.0.0 adalah titik awal API publik, setiap versi baru ditulis berdasarkan versi ini. +1. Versi 1.0.0 adalah titik awal API publik. Cara nomor versi ini dinaikkan setelah rilis ini adalah tergantung dengan API publik ini dan bagaimana ia berubah. + +1. Versi *patch* Z (x.y.Z \| x > 0) HARUS dinaikkan jika ada perbaikan bug yang kompatibel dengan versi lama. Sebuah perbaikan bug didefinisikan sebagai perubahan internal yang memperbaiki perilaku yang salah. + +1. Versi *minor* Y (x.Y.z \| x > 0) HARUS dinaikkan jika ada fitur baru yang kompatibel dengan versi lama dalam API publik. Ini HARUS dinaikkan jika sebuah fungsionalitas API publik dibuat usang. Ini BISA dinaikkan jika ada tambahan fungsionalitas substansial atau terjadi peningkatan di dalam kode privat. Ini BISA diubah bersama dengan perubahan tingkat *patch*. Versi *patch* HARUS dikembalikan ke angka 0 jika versi *minor* dinaikkan. + +1. Versi *major* X (X.y.z \| X > 0) HARUS dinaikkan jika ada perubahan yang membuat versi baru tidak kompatibel dengan versi lama pada API publik. Ini juga BISA diubah bersama dengan perubahan tingkat *patch* dan *minor*. Versi *minor* dan *patch* HARUS dikembalikan ke angka 0 jika versi *major* dinaikkan. + +1. Versi prarilis BISA ditulis dengan menambahkan tanda hubung dan rangkaian pengenal dengan pemisah titik tepat setelah versi *patch*. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda hubung [0-9A-Za-z]. Pengenal TIDAK BOLEH kosong. Pengenal numerik TIDAK BOLEH didahului angka 0. Versi prarilis memiliki presendens yang lebih rendah dibandingkan dengan versi normal yang terkait. Versi prarilis dianggap tidak stabil dan mungkin tidak memuaskan persyaratan kompatibilitas yang dimaksudkan seperti yang ditunjukkan oleh versi normal yang terkait. Contoh: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.\-\-. + +1. *Build metadata* BISA ditulis didahului dengan tanda tambah dan rangkaian pengenal dengan pemisah titik setelah versi *patch* atau prarilis. *Build metadata* HARUS ditulis dengan huruf ASCII alfanumerik dan tanda hubung [0-9A-Za-z]. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda hubung [0-9A-Za-z]. Pengenal TIDAK BOLEH kosong. *Build metadata* HARUS diabaikan saat menentukan presedens versi. Dengan begitu, dua versi yang berbada hanya di *build metadata*-nya memiliki preseden yang sama. Contoh: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3\-\-\-\-117B344092BD. + +1. Presedens mengacu pada bagaimana versi-versi dibandingkan satu sama lain ketika diurutkan. + + 1. Presedens HARUS dihitung dengan memisahkan versi menjadi pengenal *major*, *minor*, *patch*, dan prarilis dalam urutan tersebut (*Build metadata* tidak diperhitungkan dalam pengurutan). + + 1. Presedens ditentukan oleh perbedaan pertama saat membandingkan masing-masing pengenal ini dari kiri ke kanan sebagai berikut: *Major*, *minor*, dan *patch* selalu dibandingkan secara numerik. + + Contoh: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. + + 1. Saat versi *major*, *minor*, dan *patch* sama, versi prarilis lebih rendah memiliki presedens lebih rendah dibandingkan dengan versi normal: + + Contoh: 1.0.0-alpha < 1.0.0. + + 1. Prioritas untuk dua versi prarilis dengan versi *major*, *minor*, dan *patch* HARUS ditentukan dengan membandingkan setiap pengenal yang dipisahkan titik dari kiri ke kanan hingga ditemukan perbedaan sebagai berikut: + + 1. Pengenal yang hanya terdiri dari angka dibandingkan secara numerik. + + 1. Pengenal dengan huruf atau tanda hubung dibandingkan secara leksikal dalam urutan pengurutan ASCII. + + 1. Pengenal numerik selalu memiliki presedens yang lebih rendah daripada pengenal non-numerik pengenal non-numerik. + + 1. Suatu set yang lebih besar dari bidang prarilis memiliki presedens yang lebih tinggi daripada yang set yang lebih kecil, jika semua pengenal sebelumnya sama. + + Contoh: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. + +Grammar Bentuk Backus–Naur untuk Versi SemVer Valid +--------------------------------------------------- +``` + ::= + | "-" + | "+" + | "-" "+" + + ::= "." "." -6. Versi patch Z (x.y.Z | x > 0) HARUS dinaikkan jika ada perbaikan bug tanpa menambah fitur. + ::= -7. 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. + ::= -8. 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. + ::= -9. 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. + ::= -10. _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 + ::= + | "." -11. Penentuan versi mana yang didahulukan diurutkan berdasarkan versi stabil, lalu versi sebelum rilis, dan versi dengan _Build Metadata_. Jika ada versi stabil yang sama, maka diambil versi dengan angka paling tinggi. Contoh 2.0.0 lebih didahulukan dari 1.0.0. Jika ada versi sebelum rilis, maka diambil versi yang stabil terlebih dahulu. Contoh, 2.0.0 lebih didahulukan dari 2.0.0-alpha. + ::= -Kenapa Menggunakan Pemberian Versi Semantik ----------------------------- + ::= + | "." -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. + ::= "0" + | + | + + ::= + | + + ::= + | + + ::= + | "-" + + ::= + | + + ::= "0" + | + + ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" + + ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" + | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" + | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" + | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" + | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" + | "y" | "z" +``` + +Kenapa Menggunakan Pemversian Semantik? +--------------------------------------- + +Ini bukanlah ide baru yang revolusioner. Faktanya, kalian mungkin sudah menggunakan standar ini, hanya saja tidak terlalu ketat. Masalahnya, "tidak teralu ketat" saja tidak cukup bagus. Tanpa kepatuhan terhadap beberapa jenis spesifikasi formal, nomor versi adalah pada dasarnya tidak berguna untuk manajemen dependensi. Dengan memberikan nama dan definisi yang jelas definisi yang jelas untuk ide-ide tersebut, mengkomunikasikan maksud Anda kepada pengguna perangkat lunak Anda menjadi lebih mudah. Setelah maksud ini jelas, spesifikasi ketergantungan yang fleksibel (tetapi tidak terlalu fleksibel) akhirnya dapat dibuat. + +Contoh sederhana ini menunjukkan manfaat Pemversian 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 Pemversian Semantik, "MobilPemadamKebakaran" bisa dengan yakin menggunakan modul "Tangga" selama modul tersebut mempunyai versi antara 3.1.0 sampai dengan sebelum versi 4.0.0. + +Sebagai pengembang yang bertanggung jawab, tentu saja Anda ingin memverifikasi bahwa peningkatan paket berfungsi seperti yang diiklankan. Dunia nyata tidaklah pasti; tidak ada yang bisa kita lakukan selain waspada. Yang bisa Anda lakukan adalah membiarkan Pemversian Semantik memberi Anda cara yang masuk akal untuk merilis dan memutakhirkan paket tanpa harus menggulirkan versi baru dari paket dependen, membuat Anda menghemat waktu dan kerumitan. + +Jika menurut kalian aturan ini bagus, cara untuk memulai menggunakan pemversian semantik adalah dengan menautkan situs ini dalam README kalian supaya orang lain bisa tahu mengenai aturan ini dan mulai menggunakannya juga. Pertanyaan Yang Sering Diajukan ---- +------------------------------- -### Bagaimana memulai versi pengembangan 0.y.z? +### Bagaimana cara menangani revisi dalam fase pengembangan awal 0.y.z? -Paling mudah adalah memulai dengan versi 0.1.0. +Hal yang paling sederhana untuk dilakukan adalah memulai rilis pengembangan awal Anda pada 0.1.0 dan kemudian meningkatkan versi minor untuk setiap rilis berikutnya. -### Kapan harus dirilis versi 1.0.0? +### Bagaimana saya tahu kapan merilis 1.0.0? -Ketika sistem yang dikembangkan sudah stabil dan digunakan dalam lingkungan produksi, kalian bisa -mulai menentukannya dengan versi 1.0.0. +Jika perangkat lunak Anda digunakan dalam produksi, mungkin perangkat lunak Anda sudah versi 1.0.0. Jika Anda memiliki API yang stabil yang menjadi andalan pengguna, Anda harusnya sudah pada 1.0.0. Jika Anda sangat mengkhawatirkan kompatibilitas versi lama, Anda mungkin sudah pada 1.0.0. ### Bukankah standar ini mencegah perkembangan yang cepat? -Versi 0.1.0 adalah tempat dimana banyak perubahan terjadi, jadi standar ini tidak mencegah perkembangan yang cepat. +Versi *major* nol adalah tentang pengembangan yang cepat. Jika Anda mengubah API setiap hari, Anda harus tetap berada di versi 0.y.z atau di pengembangan terpisah yang bekerja pada versi *major* berikutnya. -### Jika perubahan yang tidak membuat versi lama tidak bisa dipakai sangat banyak, bukankah berarti nanti dengan cepat versi kita membengkan menjadi seperti versi 100.0.0? +### Jika perubahan terkecil yang tidak kompatibel dengan API publik memerlukan kenaikkan versi *major*, bukankah saya akan berakhir di versi 42.0.0 dengan sangat cepat? -Ini lebih ke permasalahan pengembangan, jika pengembangan dilakukan dengan seksama, maka seharusnya tidak terjadi perubahan yang terlalu signifikan dalam waktu yang cepat. +Ini adalah pertanyaan tentang pengembangan yang bertanggung jawab dan pandangan ke depan. Perubahan yang tidak kompatibel tidak boleh diperkenalkan dengan mudah ke perangkat lunak yang memiliki banyak kode dependen. Biaya yang harus dikeluarkan untuk meng-upgrade bisa sangat besar. Kewajiban mengganti versi *major* untuk merilis perubahan yang tidak kompatibel seharusnya membuat Anda memikirkan dampak dari perubahan Anda, dan mengevaluasi perbandingan biaya dan manfaat yang terkait. -### Terlalu merepotkan! +### Mendokumentasikan seluruh API publik sangatlah merepotkan! -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. +Sudah tanggung jawab Anda sebagai pengembang profesional untuk mendokumentasikan perangkat lunak untuk digunakan oleh orang lain dengan benar. Mengelola kompleksitas perangkat lunak adalah bagian yang sangat penting dalam menjaga proyek tetap efisien, dan itu sulit dilakukan jika tidak ada yang tahu cara menggunakan perangkat lunak Anda, atau metode apa yang aman untuk dihubungi. Dalam jangka panjang, Pemversian Semantik, dan desakan pada API publik yang terdefinisi dengan baik dapat membuat semua orang dan segala sesuatu berjalan dengan lancar. ### Bagaimana jika secara tidak sengaja membuat perubahan yang menjadikan versi lama tidak bisa dipakai? -Langsung ganti perubahan tersebut dan kembalikan supaya masih bisa digunakan versi lama dan naikkan versi minor. +Setelah Anda menyadari bahwa Anda telah melanggar spesifikasi Pemversian Semantik, perbaiki dan rilis versi *minor* baru yang memperbaiki masalah dan mengembalikan kompatibilitas versi lama. Bahkan dalam kondisi ini, memodifikasi rilis yang telah diberi versi adalah dilarang. Jika mau, dokumentasikan versi yang bermasalah dan memberi tahu pengguna Anda tentang masalah tersebut sehingga mereka mengetahui versi yang bermasalah. -### Bagaimana jika saya merubah kebutuhan sistem tanpa merubah API publik? +### Apa yang harus saya lakukan jika saya memperbarui dependensi saya sendiri tanpa mengubah API publik? -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. +Hal tersebut dianggap kompatibel karena tidak mempengaruhi API publik. Perangkat lunak yang secara eksplisit bergantung pada dependensi yang sama dengan paket Anda harus memiliki spesifikasi dependensi mereka sendiri dan pembuatnya akan memberi tahu konflik yang ada. Menentukan apakah perubahan tersebut merupakan tingkat *patch* atau tingkat *minor* tergantung pada apakah Anda memperbarui dependensi untuk memperbaiki *bug* atau memperkenalkan fungsionalitas baru. Kami biasanya mengharapkan kode tambahan untuk contoh yang kedua, yang dalam hal ini jelas merupakan kenaikan tingkat *minor*. -### Bagaimana jika perubahan yang terjadi ternyata sangat besar dan sudah dirilis di versi patch? +### Bagaimana jika saya secara tidak sengaja mengubah API publik dengan cara yang tidak sesuai dengan perubahan nomor versi (misalnya, kode secara tidak benar memperkenalkan perubahan besar dalam rilis *patch*)? -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. +Gunakan kebijakan terbaik Anda. Jika Anda memiliki audiens yang sangat besar yang akan terpengaruh secara drastis dengan apa yang dimaksudkan oleh API publik, maka lebih baik melakukan rilis versi *major*, meskipun perbaikannya dapat sangat dianggap sebagai rilis *patch*. Ingat, Pemversian Semantik adalah segalanya tentang menyampaikan makna melalui perubahan nomor versi. Jika perubahan ini perubahan ini penting bagi pengguna Anda, gunakan nomor versi itu untuk memberi tahu mereka. -### Bagaimana jika ada fitur yang usang? +### Bagaimana cara menangani fungsionalitas yang sudah diusangkan? -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. +Mengusangkan fungsionalitas yang ada adalah hal yang lumrah dalam pengembangan perangkat lunak dan sering kali diperlukan untuk membuat suatu kemajuan. Ketika Anda mengusangkan bagian dari API publik Anda, Anda harus melakukan dua hal: (1) memperbarui dokumentasi Anda untuk memberi tahu pengguna tahu tentang perubahan tersebut, dan (2) mengeluarkan rilis minor baru dengan penghentian yang baru dengan pengusangan itu dibuat. Sebelum Anda benar-benar menghapus fungsionalitas dalam rilis *major* yang baru harus ada setidaknya satu rilis *minor* yang berisi pengusangan itu sehingga pengguna dapat beralih dengan lancar ke API yang baru. ### Apakah Versi Semantik punya batasan jumlah karakter dalam versi? -Tidak ada, tapi sebaiknya gunakan saja secukupnya. Versi sepanjang 255 terlalu banyak dan membuat pengguna kesulitan untuk membacanya. +Tidak, tetapi gunakan kebijakan yang baik. Misalnya, versi dengan panjang 255 karakter mungkin teralu banyak. Selain itu, sistem tertentu mungkin memiliki batasan mereka sendiri pada ukuran string. + +### Apakah ada *regular expression* (RegEx) yang disarankan untuk memeriksa string SemVer? + +Ada dua. Satu dengan grup bernama untuk sistem yang didukung (PCRE [Perl Compatible Regular Expressions, yaitu Perl, PHP dan R], Python dan Go). + +Lihat: + +``` +^(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` + +Dan satu lagi dengan kelompok tangkapan bernomor (jadi cg1 = *major*, cg2 = *minor*, cg3 = *patch*, cg4 = prarilis dan cg5 = *build metadata*) yang kompatibel dengan ECMA Script (JavaScript), PCRE (Perl Compatible Regular Expressions, +yaitu Perl, PHP dan R), Python dan Go. + +``` +^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` Tentang ------ +------- -Spesifikasi Versi Semantik dibuat oleh [Tom Preston-Werner](http://tom.preston-werner.com), pembuat Gravatars dan -cofounder dari GitHub. +Spesifikasi Pemversian Semantik awalnya dibuat oleh [Tom Preston-Werner](http://tom.preston-werner.com), pembuat Gravatar dan *cofounder* dari GitHub. -Translasi Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com) dan dikoreksi oleh -[Christian B. Wibowo](https://github.com/cwibowo). +Terjemahan Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com), [Christian B. Wibowo](https://github.com/cwibowo), dan [Hans5958](https://github.com/Hans5958). -Untuk saran dan kritik, [buka issue di GitHub](https://github.com/mojombo/semver/issues). +Untuk saran dan kritik, silahkan [buka issue di GitHub](https://github.com/semver/semver/issues). Lisensi ------- diff --git a/lang/id/spec/v0.1.0.md b/lang/id/spec/v0.1.0.md new file mode 100644 index 00000000..5be3afed --- /dev/null +++ b/lang/id/spec/v0.1.0.md @@ -0,0 +1,83 @@ +--- +title: Pemversian Semantik 0.1.0 +language: id +--- + +Pemversian Semantik 0.1.0 +========================= + +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 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 berasumsi versi mana yang bisa digunakan dengan versi yang lain. *Dependency hell* adalah saat Anda berada pada satu atau dua masalah ini, yang menahan Anda untuk bergerak maju dengan aman dan mudah. + +Sebagai solusi permasalahan ini, saya mengusulkan seperangkat aturan dan persayaratan sederhana yang menentukan bagaimana nomor versi diberikan dan bertambah. Agar sistem ini dapat bekerja, Anda harus mengumumkan API publik terlebih dahulu. Ini dapat terdiri dari dokumentasi atau diberlakukan oleh kode itu sendiri. Apapun itu, API ini harus jelas dan tepat. Setelah Anda mengidentifikasi API publik Anda, Anda mengomunikasikan perubahan pada API tersebut dengan penambahan spesifik pada nomor versi Anda. Pertimbangkan format versi X.Y.Z (Major.Minor.Patch). Perbaikan bug yang tidak memengaruhi API tersebut akan menambah versi *patch*, penambahan/perubahan API yang kompatibel dengan versi sebelumnya akan menambah versi *minor*, dan perubahan API yang tidak kompatibel dengan versi sebelumnya akan menambah versi major. + +Standar ini bernama "Pemversian Semantik". Dengan skema ini, setiap orang yang melihat angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut. + +Spesifikasi Pemversian Semantik +------------------------------- + +1. Perangkat lunak dengan Pemversian Semantik HARUS menentukan API public. Bisa dijelaskan dengan kode, atau ditulis di dokumentasi saja. Apapun itu harus ditulis dengan jelas dan akurat. + +1. Sebuah versi memiliki bentuk X.Y.Z, dengan X, Y, dan Z adalah bilangan bulat. X adalah versi *major*, Y adalah *minor*, dan Z adalah *patch*. Setiap elemen bertambah secara numerik seperti versi 1.0.10 muncul setelah 1.0.9 + +1. Saat menandai rilis dalam sistem kontrol versi, *tag* untuk sebuah versi HARUS "vX.Y.Z", seperti "v3.1.0". + +1. Setelah sebuah paket berversi dirilis, isi dari versi tersebut TIDAK BOLEH diubah. Setiap perubahan harus dirilis sebagai versi baru. + +1. Versi *major* 0 (0.y.z) adalah untuk pengembangan awal. Apapun bisa bisa berubah kapanpun. API publik sebaiknya dianggap tidak stabil di versi ini. + +1. Versi 1.0.0 adalah titik awal API publik. Cara nomor versi ini sekarang tergantung dengan API publik ini dan bagaimana ia berubah. + +1. Versi *patch* Z (x.y.Z \| x > 0) HARUS dinaikkan jika ada perbaikan bug yang kompatibel dengan versi lama. Sebuah perbaikan bug didefinisikan sebagai perubahan internal yang memperbaiki perilaku yang salah. + +1. Versi *minor* Y (x.Y.z \| x > 0) HARUS dinaikkan jika ada fitur baru yang kompatibel dengan versi lama dalam API publik. Ini BISA dinaikkan jika ada tambahan fungsionalitas substansial atau terjadi peningkatan di dalam kode privat. Ini BISA diubah bersama dengan perubahan tingkat *patch*. + +1. Versi *major* X (X.y.z \| X > 0) HARUS dinaikkan jika ada perubahan yang membuat versi baru tidak kompatibel dengan versi lama pada API publik. Ini BISA diubah bersama dengan perubahan tingkat *patch* dan *minor*. + +Kenapa Menggunakan Pemversian Semantik? +--------------------------------------- + +Ini bukanlah ide baru yang revolusioner. Faktanya, kalian mungkin sudah menggunakan standar ini, hanya saja tidak terlalu ketat. Masalahnya, "tidak teralu ketat" saja tidak cukup bagus. Tanpa kepatuhan terhadap beberapa jenis spesifikasi formal, nomor versi adalah pada dasarnya tidak berguna untuk manajemen dependensi. Dengan memberikan nama dan definisi yang jelas definisi yang jelas untuk ide-ide tersebut, mengkomunikasikan maksud Anda kepada pengguna perangkat lunak Anda menjadi lebih mudah. Setelah maksud ini jelas, spesifikasi ketergantungan yang fleksibel (tetapi tidak terlalu fleksibel) akhirnya dapat dibuat. + +Contoh sederhana ini menunjukkan manfaat Pemversian 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 Pemversian Semantik, "MobilPemadamKebakaran" bisa dengan yakin menggunakan modul "Tangga" selama modul tersebut mempunyai versi antara 3.1.0 sampai dengan sebelum versi 4.0.0. + +Sebagai pengembang yang bertanggung jawab, tentu saja Anda ingin memverifikasi bahwa peningkatan paket berfungsi seperti yang diiklankan. Dunia nyata tidaklah pasti; tidak ada yang bisa kita lakukan selain waspada. Yang bisa Anda lakukan adalah membiarkan Pemversian Semantik memberi Anda cara yang masuk akal untuk merilis dan memutakhirkan paket tanpa harus menggulirkan versi baru dari paket dependen, membuat Anda menghemat waktu dan kerumitan. + +Jika menurut kalian aturan ini bagus, cara untuk memulai menggunakan pemversian semantik adalah dengan menautkan situs ini dalam README kalian supaya orang lain bisa tahu mengenai aturan ini dan mulai menggunakannya juga. + +Pertanyaan Yang Sering Diajukan +------------------------------- + +### Bagaimana saya tahu kapan merilis 1.0.0? + +Jika perangkat lunak Anda digunakan dalam produksi, mungkin perangkat lunak Anda sudah versi 1.0.0. Jika Anda memiliki API yang stabil yang menjadi andalan pengguna, Anda harusnya sudah pada 1.0.0. Jika Anda sangat mengkhawatirkan kompatibilitas versi lama, Anda mungkin sudah pada 1.0.0. + +### Bukankah standar ini mencegah perkembangan yang cepat? + +Versi *major* nol adalah tentang pengembangan yang cepat. Jika Anda mengubah API setiap hari, Anda harus tetap berada di versi 0.x.x atau di pengembangan terpisah yang bekerja pada versi *major* berikutnya. + +### Jika perubahan terkecil yang tidak kompatibel dengan API publik memerlukan kenaikkan versi *major*, bukankah saya akan berakhir di versi 42.0.0 dengan sangat cepat? + +Ini adalah pertanyaan tentang pengembangan yang bertanggung jawab dan pandangan ke depan. Perubahan yang tidak kompatibel tidak boleh diperkenalkan dengan mudah ke perangkat lunak yang memiliki banyak kode dependen. Biaya yang harus dikeluarkan untuk meng-upgrade bisa sangat besar. Kewajiban mengganti versi *major* untuk merilis perubahan yang tidak kompatibel seharusnya membuat Anda memikirkan dampak dari perubahan Anda, dan mengevaluasi perbandingan biaya dan manfaat yang terkait. + +### Mendokumentasikan seluruh API publik sangatlah merepotkan! + +Sudah tanggung jawab Anda sebagai pengembang profesional untuk mendokumentasikan perangkat lunak untuk digunakan oleh orang lain dengan benar. Mengelola kompleksitas perangkat lunak adalah bagian yang sangat penting dalam menjaga proyek tetap efisien, dan itu sulit dilakukan jika tidak ada yang tahu cara menggunakan perangkat lunak Anda, atau metode apa yang aman untuk dihubungi. Dalam jangka panjang, Pemversian Semantik, dan desakan pada API publik yang terdefinisi dengan baik dapat membuat semua orang dan segala sesuatu berjalan dengan lancar. + +### Bagaimana jika secara tidak sengaja membuat perubahan yang menjadikan versi lama tidak bisa dipakai? + +Setelah Anda menyadari bahwa Anda telah melanggar spesifikasi Pemversian Semantik, perbaiki dan rilis versi *minor* baru yang memperbaiki masalah dan mengembalikan kompatibilitas versi lama. Ingat, memodifikasi rilis yang telah diberi versi adalah dilarang, bahkan dalam kondisi ini. Jika mau, dokumentasikan versi yang bermasalah dan memberi tahu pengguna Anda tentang masalah tersebut sehingga mereka mengetahui versi yang bermasalah. + +### Apa yang harus saya lakukan jika saya memperbarui dependensi saya sendiri tanpa mengubah API publik? + +Hal tersebut dianggap kompatibel karena tidak mempengaruhi API publik. Perangkat lunak yang secara eksplisit bergantung pada dependensi yang sama dengan paket Anda harus memiliki spesifikasi dependensi mereka sendiri dan pembuatnya akan memberi tahu konflik yang ada. Menentukan apakah perubahan tersebut merupakan tingkat *patch* atau tingkat *minor* tergantung pada apakah Anda memperbarui dependensi untuk memperbaiki *bug* atau memperkenalkan fungsionalitas baru. Saya biasanya mengharapkan kode tambahan untuk contoh yang kedua, yang dalam hal ini jelas merupakan kenaikan tingkat *minor*. + +Tentang +------- + +Spesifikasi Pemversian Semantik dibuat oleh [Tom Preston-Werner](http://tom.preston-werner.com), pembuat Gravatars dan *cofounder* dari GitHub. + +Terjemahan Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com), [Christian B. Wibowo](https://github.com/cwibowo), dan [Hans5958](https://github.com/Hans5958). + +Untuk saran dan kritik, silahkan [buka issue di GitHub](https://github.com/mojombo/semver/issues). diff --git a/lang/id/spec/v0.2.0.md b/lang/id/spec/v0.2.0.md new file mode 100644 index 00000000..bb3df6c5 --- /dev/null +++ b/lang/id/spec/v0.2.0.md @@ -0,0 +1,98 @@ +--- +title: Pemversian Semantik 0.2.0 +language: id +--- + +Pemversian Semantik 0.2.0 +========================= + +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 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 berasumsi versi mana yang bisa digunakan dengan versi yang lain. *Dependency hell* adalah saat Anda berada pada satu atau dua masalah ini, yang menahan Anda untuk bergerak maju dengan aman dan mudah. + +Sebagai solusi permasalahan ini, saya mengusulkan seperangkat aturan dan persayaratan sederhana yang menentukan bagaimana nomor versi diberikan dan bertambah. Agar sistem ini dapat bekerja, Anda harus mengumumkan API publik terlebih dahulu. Ini dapat terdiri dari dokumentasi atau diberlakukan oleh kode itu sendiri. Apapun itu, API ini harus jelas dan tepat. Setelah Anda mengidentifikasi API publik Anda, Anda mengomunikasikan perubahan pada API tersebut dengan penambahan spesifik pada nomor versi Anda. Pertimbangkan format versi X.Y.Z (Major.Minor.Patch). Perbaikan bug yang tidak memengaruhi API tersebut akan menambah versi *patch*, penambahan/perubahan API yang kompatibel dengan versi sebelumnya akan menambah versi *minor*, dan perubahan API yang tidak kompatibel dengan versi sebelumnya akan menambah versi major. + +Standar ini bernama "Pemversian Semantik". Dengan skema ini, setiap orang yang melihat angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut. + +Spesifikasi Pemversian Semantik (SemVer) +---------------------------------------- + +Kata/frasa "HARUS" ("MUST"), "TIDAK BOLEH" ("MUST NOT"), "DIBUTUHKAN" ("REQUIRED"), "SEHARUSNYA" ("SHALL"), "JANGAN SAMPAI" ("SHALL NOT"), "SEBAIKNYA" ("SHOULD"), "SEBAIKNYA TIDAK" ("SHOULD NOT"), "DIREKOMENDASIKAN" ("RECOMMENDED"), "BISA" ("MAY") , dan "OPSIONAL" di dokumen ini sesuai dengan RFC 2119. + +1. Perangkat lunak dengan Pemversian Semantik HARUS menentukan API public. Bisa dijelaskan dengan kode, atau ditulis di dokumentasi saja. Apapun itu harus ditulis dengan jelas dan akurat. + +1. Versi normal HARUS ditulis dalam bentuk X.Y.Z, dengan X, Y, dan Z adalah bilangan bulat. X adalah versi *major*, Y adalah *minor*, dan Z adalah *patch*. Setiap elemen HARUS bertambah secara numerik. Contohnya: 1.9.0 < 1.10.0 < 1.11.0 + +1. Versi khusus BISA ditulis dengan menambahkan titik dan rangkaian pengenal dengan pemisah titik tepat setelah versi *patch*. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda pisah [0-9A-Za-z] dan HARUS mulai dengan sebuah huruf [A-Za-z]. Versi khusus diperbolehkan, namun memiliki presendens yang lebih rendah dibandingkan dengan versi normal. Presedens SEBAIKNYA ditentukan dari urutan leksikografik ASCII. Contoh: 1.0.0beta1 < 1.0.0beta2 < 1.0.0. + +1. Setelah sebuah paket berversi dirilis, isi dari versi tersebut TIDAK BOLEH diubah. Setiap perubahan harus dirilis sebagai versi baru. + +1. Versi *major* 0 (0.y.z) adalah untuk pengembangan awal. Apapun bisa bisa berubah kapanpun. API publik sebaiknya dianggap tidak stabil di versi ini. + +1. Versi 1.0.0 adalah titik awal API publik. Cara nomor versi ini sekarang tergantung dengan API publik ini dan bagaimana ia berubah. + +1. Versi *patch* Z (x.y.Z \| x > 0) HARUS dinaikkan jika ada perbaikan bug yang kompatibel dengan versi lama. Sebuah perbaikan bug didefinisikan sebagai perubahan internal yang memperbaiki perilaku yang salah. + +1. Versi *minor* Y (x.Y.z \| x > 0) HARUS dinaikkan jika ada fitur baru yang kompatibel dengan versi lama dalam API publik. Ini BISA dinaikkan jika ada tambahan fungsionalitas substansial atau terjadi peningkatan di dalam kode privat. Ini BISA diubah bersama dengan perubahan tingkat *patch*. + +1. Versi *major* X (X.y.z \| X > 0) HARUS dinaikkan jika ada perubahan yang membuat versi baru tidak kompatibel dengan versi lama pada API publik. Ini BISA diubah bersama dengan perubahan tingkat *patch* dan *minor*. + +Spesifikasi Penandaan (SemVerTag) +--------------------------------- + +Subspesifikasi ini SEBAIKNYA digunakan jika Anda menggunakan sistem kontrol versi (Git, Mercurial, SVN, dll) untuk menyimpan kode Anda. Dengan menggunaakan sistem ini, alat otomatis dapat memeriksa paket Anda dan menentukan kepatuhan SemVer dan versi yang dirilis. + +1. Saat menandai rilis dalam sistem kontrol versi, *tag* untuk sebuah versi HARUS "vX.Y.Z", seperti "v3.1.0". + +2. Revisi pertama yang memperkenalkan kepatuhan SemVer SEBAIKNYA diberi *tag* "semver". Hal ini memungkinkan proyek yang sudah ada sebelumnya untuk mengasumsikan kepatuhan pada suatu titik dan agar alat otomatis tahu tentang hal ini. + +Kenapa Menggunakan Pemversian Semantik? +--------------------------------------- + +Ini bukanlah ide baru yang revolusioner. Faktanya, kalian mungkin sudah menggunakan standar ini, hanya saja tidak terlalu ketat. Masalahnya, "tidak teralu ketat" saja tidak cukup bagus. Tanpa kepatuhan terhadap beberapa jenis spesifikasi formal, nomor versi adalah pada dasarnya tidak berguna untuk manajemen dependensi. Dengan memberikan nama dan definisi yang jelas definisi yang jelas untuk ide-ide tersebut, mengkomunikasikan maksud Anda kepada pengguna perangkat lunak Anda menjadi lebih mudah. Setelah maksud ini jelas, spesifikasi ketergantungan yang fleksibel (tetapi tidak terlalu fleksibel) akhirnya dapat dibuat. + +Contoh sederhana ini menunjukkan manfaat Pemversian 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 Pemversian Semantik, "MobilPemadamKebakaran" bisa dengan yakin menggunakan modul "Tangga" selama modul tersebut mempunyai versi antara 3.1.0 sampai dengan sebelum versi 4.0.0. + +Sebagai pengembang yang bertanggung jawab, tentu saja Anda ingin memverifikasi bahwa peningkatan paket berfungsi seperti yang diiklankan. Dunia nyata tidaklah pasti; tidak ada yang bisa kita lakukan selain waspada. Yang bisa Anda lakukan adalah membiarkan Pemversian Semantik memberi Anda cara yang masuk akal untuk merilis dan memutakhirkan paket tanpa harus menggulirkan versi baru dari paket dependen, membuat Anda menghemat waktu dan kerumitan. + +Jika menurut kalian aturan ini bagus, cara untuk memulai menggunakan pemversian semantik adalah dengan menautkan situs ini dalam README kalian supaya orang lain bisa tahu mengenai aturan ini dan mulai menggunakannya juga. + +Pertanyaan Yang Sering Diajukan +------------------------------- + +### Bagaimana saya tahu kapan merilis 1.0.0? + +Jika perangkat lunak Anda digunakan dalam produksi, mungkin perangkat lunak Anda sudah versi 1.0.0. Jika Anda memiliki API yang stabil yang menjadi andalan pengguna, Anda harusnya sudah pada 1.0.0. Jika Anda sangat mengkhawatirkan kompatibilitas versi lama, Anda mungkin sudah pada 1.0.0. + +### Bukankah standar ini mencegah perkembangan yang cepat? + +Versi *major* nol adalah tentang pengembangan yang cepat. Jika Anda mengubah API setiap hari, Anda harus tetap berada di versi 0.x.x atau di pengembangan terpisah yang bekerja pada versi *major* berikutnya. + +### Jika perubahan terkecil yang tidak kompatibel dengan API publik memerlukan kenaikkan versi *major*, bukankah saya akan berakhir di versi 42.0.0 dengan sangat cepat? + +Ini adalah pertanyaan tentang pengembangan yang bertanggung jawab dan pandangan ke depan. Perubahan yang tidak kompatibel tidak boleh diperkenalkan dengan mudah ke perangkat lunak yang memiliki banyak kode dependen. Biaya yang harus dikeluarkan untuk meng-upgrade bisa sangat besar. Kewajiban mengganti versi *major* untuk merilis perubahan yang tidak kompatibel seharusnya membuat Anda memikirkan dampak dari perubahan Anda, dan mengevaluasi perbandingan biaya dan manfaat yang terkait. + +### Mendokumentasikan seluruh API publik sangatlah merepotkan! + +Sudah tanggung jawab Anda sebagai pengembang profesional untuk mendokumentasikan perangkat lunak untuk digunakan oleh orang lain dengan benar. Mengelola kompleksitas perangkat lunak adalah bagian yang sangat penting dalam menjaga proyek tetap efisien, dan itu sulit dilakukan jika tidak ada yang tahu cara menggunakan perangkat lunak Anda, atau metode apa yang aman untuk dihubungi. Dalam jangka panjang, Pemversian Semantik, dan desakan pada API publik yang terdefinisi dengan baik dapat membuat semua orang dan segala sesuatu berjalan dengan lancar. + +### Bagaimana jika secara tidak sengaja membuat perubahan yang menjadikan versi lama tidak bisa dipakai? + +Setelah Anda menyadari bahwa Anda telah melanggar spesifikasi Pemversian Semantik, perbaiki dan rilis versi *minor* baru yang memperbaiki masalah dan mengembalikan kompatibilitas versi lama. Ingat, memodifikasi rilis yang telah diberi versi adalah dilarang, bahkan dalam kondisi ini. Jika mau, dokumentasikan versi yang bermasalah dan memberi tahu pengguna Anda tentang masalah tersebut sehingga mereka mengetahui versi yang bermasalah. + +### Apa yang harus saya lakukan jika saya memperbarui dependensi saya sendiri tanpa mengubah API publik? + +Hal tersebut dianggap kompatibel karena tidak mempengaruhi API publik. Perangkat lunak yang secara eksplisit bergantung pada dependensi yang sama dengan paket Anda harus memiliki spesifikasi dependensi mereka sendiri dan pembuatnya akan memberi tahu konflik yang ada. Menentukan apakah perubahan tersebut merupakan tingkat *patch* atau tingkat *minor* tergantung pada apakah Anda memperbarui dependensi untuk memperbaiki *bug* atau memperkenalkan fungsionalitas baru. Saya biasanya mengharapkan kode tambahan untuk contoh yang kedua, yang dalam hal ini jelas merupakan kenaikan tingkat *minor*. + +### Apa yang harus saya lakukan jika bug yang sedang diperbaiki mengembalikan kode agar sesuai dengan API publik (misalnya, kode tidak sinkron dengan dokumentasi API publik)? + +Gunakan kebijakan terbaik Anda. Jika Anda memiliki audiens yang sangat besar yang akan terpengaruh secara drastis dengan apa yang dimaksudkan oleh API publik, maka lebih baik melakukan rilis versi *major*, meskipun perbaikannya dapat sangat dianggap sebagai rilis *patch*. Ingat, Pemversian Semantik adalah segalanya tentang menyampaikan makna melalui perubahan nomor versi. Jika perubahan ini perubahan ini penting bagi pengguna Anda, gunakan nomor versi itu untuk memberi tahu mereka. + +Tentang +------- + +Spesifikasi Pemversian Semantik dibuat oleh [Tom Preston-Werner](http://tom.preston-werner.com), pembuat Gravatars dan *cofounder* dari GitHub. + +Terjemahan Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com), [Christian B. Wibowo](https://github.com/cwibowo), dan [Hans5958](https://github.com/Hans5958). + +Untuk saran dan kritik, silahkan [buka issue di GitHub](https://github.com/mojombo/semver/issues). diff --git a/lang/id/spec/v0.9.0.md b/lang/id/spec/v0.9.0.md new file mode 100644 index 00000000..296dac19 --- /dev/null +++ b/lang/id/spec/v0.9.0.md @@ -0,0 +1,98 @@ +--- +title: Pemversian Semantik 0.9.0 +language: id +--- + +Pemversian Semantik 0.2.0 +========================= + +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 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 berasumsi versi mana yang bisa digunakan dengan versi yang lain. *Dependency hell* adalah saat Anda berada pada satu atau dua masalah ini, yang menahan Anda untuk bergerak maju dengan aman dan mudah. + +Sebagai solusi permasalahan ini, saya mengusulkan seperangkat aturan dan persayaratan sederhana yang menentukan bagaimana nomor versi diberikan dan bertambah. Agar sistem ini dapat bekerja, Anda harus mengumumkan API publik terlebih dahulu. Ini dapat terdiri dari dokumentasi atau diberlakukan oleh kode itu sendiri. Apapun itu, API ini harus jelas dan tepat. Setelah Anda mengidentifikasi API publik Anda, Anda mengomunikasikan perubahan pada API tersebut dengan penambahan spesifik pada nomor versi Anda. Pertimbangkan format versi X.Y.Z (Major.Minor.Patch). Perbaikan bug yang tidak memengaruhi API tersebut akan menambah versi *patch*, penambahan/perubahan API yang kompatibel dengan versi sebelumnya akan menambah versi *minor*, dan perubahan API yang tidak kompatibel dengan versi sebelumnya akan menambah versi major. + +Standar ini bernama "Pemversian Semantik". Dengan skema ini, setiap orang yang melihat angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut. + +Spesifikasi Pemversian Semantik (SemVer) +---------------------------------------- + +Kata/frasa "HARUS" ("MUST"), "TIDAK BOLEH" ("MUST NOT"), "DIBUTUHKAN" ("REQUIRED"), "SEHARUSNYA" ("SHALL"), "JANGAN SAMPAI" ("SHALL NOT"), "SEBAIKNYA" ("SHOULD"), "SEBAIKNYA TIDAK" ("SHOULD NOT"), "DIREKOMENDASIKAN" ("RECOMMENDED"), "BISA" ("MAY") , dan "OPSIONAL" di dokumen ini sesuai dengan RFC 2119. + +1. Perangkat lunak dengan Pemversian Semantik HARUS menentukan API public. Bisa dijelaskan dengan kode, atau ditulis di dokumentasi saja. Apapun itu harus ditulis dengan jelas dan akurat. + +1. Versi normal HARUS ditulis dalam bentuk X.Y.Z, dengan X, Y, dan Z adalah bilangan bulat. X adalah versi *major*, Y adalah *minor*, dan Z adalah *patch*. Setiap elemen HARUS bertambah secara numerik. Contohnya: 1.9.0 < 1.10.0 < 1.11.0 + +1. Versi khusus BISA ditulis dengan menambahkan titik dan rangkaian pengenal dengan pemisah titik tepat setelah versi *patch*. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda pisah [0-9A-Za-z] dan HARUS mulai dengan sebuah huruf [A-Za-z]. Versi khusus diperbolehkan, namun memiliki presendens yang lebih rendah dibandingkan dengan versi normal. Presedens SEBAIKNYA ditentukan dari urutan leksikografik ASCII. Contoh: 1.0.0beta1 < 1.0.0beta2 < 1.0.0. + +1. Setelah sebuah paket berversi dirilis, isi dari versi tersebut TIDAK BOLEH diubah. Setiap perubahan harus dirilis sebagai versi baru. + +1. Versi *major* 0 (0.y.z) adalah untuk pengembangan awal. Apapun bisa bisa berubah kapanpun. API publik sebaiknya dianggap tidak stabil di versi ini. + +1. Versi 1.0.0 adalah titik awal API publik. Cara nomor versi ini sekarang tergantung dengan API publik ini dan bagaimana ia berubah. + +1. Versi *patch* Z (x.y.Z \| x > 0) HARUS dinaikkan jika ada perbaikan bug yang kompatibel dengan versi lama. Sebuah perbaikan bug didefinisikan sebagai perubahan internal yang memperbaiki perilaku yang salah. + +1. Versi *minor* Y (x.Y.z \| x > 0) HARUS dinaikkan jika ada fitur baru yang kompatibel dengan versi lama dalam API publik. Ini BISA dinaikkan jika ada tambahan fungsionalitas substansial atau terjadi peningkatan di dalam kode privat. Ini BISA diubah bersama dengan perubahan tingkat *patch*. + +1. Versi *major* X (X.y.z \| X > 0) HARUS dinaikkan jika ada perubahan yang membuat versi baru tidak kompatibel dengan versi lama pada API publik. Ini BISA diubah bersama dengan perubahan tingkat *patch* dan *minor*. + +Spesifikasi Penandaan (SemVerTag) +--------------------------------- + +Subspesifikasi ini SEBAIKNYA digunakan jika Anda menggunakan sistem kontrol versi (Git, Mercurial, SVN, dll) untuk menyimpan kode Anda. Dengan menggunaakan sistem ini, alat otomatis dapat memeriksa paket Anda dan menentukan kepatuhan SemVer dan versi yang dirilis. + +1. Saat menandai rilis dalam sistem kontrol versi, *tag* untuk sebuah versi HARUS "vX.Y.Z", seperti "v3.1.0". + +2. Revisi pertama yang memperkenalkan kepatuhan SemVer SEBAIKNYA diberi *tag* "semver". Hal ini memungkinkan proyek yang sudah ada sebelumnya untuk mengasumsikan kepatuhan pada suatu titik dan agar alat otomatis tahu tentang hal ini. + +Kenapa Menggunakan Pemversian Semantik? +--------------------------------------- + +Ini bukanlah ide baru yang revolusioner. Faktanya, kalian mungkin sudah menggunakan standar ini, hanya saja tidak terlalu ketat. Masalahnya, "tidak teralu ketat" saja tidak cukup bagus. Tanpa kepatuhan terhadap beberapa jenis spesifikasi formal, nomor versi adalah pada dasarnya tidak berguna untuk manajemen dependensi. Dengan memberikan nama dan definisi yang jelas definisi yang jelas untuk ide-ide tersebut, mengkomunikasikan maksud Anda kepada pengguna perangkat lunak Anda menjadi lebih mudah. Setelah maksud ini jelas, spesifikasi ketergantungan yang fleksibel (tetapi tidak terlalu fleksibel) akhirnya dapat dibuat. + +Contoh sederhana ini menunjukkan manfaat Pemversian 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 Pemversian Semantik, "MobilPemadamKebakaran" bisa dengan yakin menggunakan modul "Tangga" selama modul tersebut mempunyai versi antara 3.1.0 sampai dengan sebelum versi 4.0.0. + +Sebagai pengembang yang bertanggung jawab, tentu saja Anda ingin memverifikasi bahwa peningkatan paket berfungsi seperti yang diiklankan. Dunia nyata tidaklah pasti; tidak ada yang bisa kita lakukan selain waspada. Yang bisa Anda lakukan adalah membiarkan Pemversian Semantik memberi Anda cara yang masuk akal untuk merilis dan memutakhirkan paket tanpa harus menggulirkan versi baru dari paket dependen, membuat Anda menghemat waktu dan kerumitan. + +Jika menurut kalian aturan ini bagus, cara untuk memulai menggunakan pemversian semantik adalah dengan menautkan situs ini dalam README kalian supaya orang lain bisa tahu mengenai aturan ini dan mulai menggunakannya juga. + +Pertanyaan Yang Sering Diajukan +------------------------------- + +### Bagaimana saya tahu kapan merilis 1.0.0? + +Jika perangkat lunak Anda digunakan dalam produksi, mungkin perangkat lunak Anda sudah versi 1.0.0. Jika Anda memiliki API yang stabil yang menjadi andalan pengguna, Anda harusnya sudah pada 1.0.0. Jika Anda sangat mengkhawatirkan kompatibilitas versi lama, Anda mungkin sudah pada 1.0.0. + +### Bukankah standar ini mencegah perkembangan yang cepat? + +Versi *major* nol adalah tentang pengembangan yang cepat. Jika Anda mengubah API setiap hari, Anda harus tetap berada di versi 0.x.x atau di pengembangan terpisah yang bekerja pada versi *major* berikutnya. + +### Jika perubahan terkecil yang tidak kompatibel dengan API publik memerlukan kenaikkan versi *major*, bukankah saya akan berakhir di versi 42.0.0 dengan sangat cepat? + +Ini adalah pertanyaan tentang pengembangan yang bertanggung jawab dan pandangan ke depan. Perubahan yang tidak kompatibel tidak boleh diperkenalkan dengan mudah ke perangkat lunak yang memiliki banyak kode dependen. Biaya yang harus dikeluarkan untuk meng-upgrade bisa sangat besar. Kewajiban mengganti versi *major* untuk merilis perubahan yang tidak kompatibel seharusnya membuat Anda memikirkan dampak dari perubahan Anda, dan mengevaluasi perbandingan biaya dan manfaat yang terkait. + +### Mendokumentasikan seluruh API publik sangatlah merepotkan! + +Sudah tanggung jawab Anda sebagai pengembang profesional untuk mendokumentasikan perangkat lunak untuk digunakan oleh orang lain dengan benar. Mengelola kompleksitas perangkat lunak adalah bagian yang sangat penting dalam menjaga proyek tetap efisien, dan itu sulit dilakukan jika tidak ada yang tahu cara menggunakan perangkat lunak Anda, atau metode apa yang aman untuk dihubungi. Dalam jangka panjang, Pemversian Semantik, dan desakan pada API publik yang terdefinisi dengan baik dapat membuat semua orang dan segala sesuatu berjalan dengan lancar. + +### Bagaimana jika secara tidak sengaja membuat perubahan yang menjadikan versi lama tidak bisa dipakai? + +Setelah Anda menyadari bahwa Anda telah melanggar spesifikasi Pemversian Semantik, perbaiki dan rilis versi *minor* baru yang memperbaiki masalah dan mengembalikan kompatibilitas versi lama. Ingat, memodifikasi rilis yang telah diberi versi adalah dilarang, bahkan dalam kondisi ini. Jika mau, dokumentasikan versi yang bermasalah dan memberi tahu pengguna Anda tentang masalah tersebut sehingga mereka mengetahui versi yang bermasalah. + +### Apa yang harus saya lakukan jika saya memperbarui dependensi saya sendiri tanpa mengubah API publik? + +Hal tersebut dianggap kompatibel karena tidak mempengaruhi API publik. Perangkat lunak yang secara eksplisit bergantung pada dependensi yang sama dengan paket Anda harus memiliki spesifikasi dependensi mereka sendiri dan pembuatnya akan memberi tahu konflik yang ada. Menentukan apakah perubahan tersebut merupakan tingkat *patch* atau tingkat *minor* tergantung pada apakah Anda memperbarui dependensi untuk memperbaiki *bug* atau memperkenalkan fungsionalitas baru. Saya biasanya mengharapkan kode tambahan untuk contoh yang kedua, yang dalam hal ini jelas merupakan kenaikan tingkat *minor*. + +### Apa yang harus saya lakukan jika bug yang sedang diperbaiki mengembalikan kode agar sesuai dengan API publik (misalnya, kode tidak sinkron dengan dokumentasi API publik)? + +Gunakan kebijakan terbaik Anda. Jika Anda memiliki audiens yang sangat besar yang akan terpengaruh secara drastis dengan apa yang dimaksudkan oleh API publik, maka lebih baik melakukan rilis versi *major*, meskipun perbaikannya dapat sangat dianggap sebagai rilis *patch*. Ingat, Pemversian Semantik adalah segalanya tentang menyampaikan makna melalui perubahan nomor versi. Jika perubahan ini perubahan ini penting bagi pengguna Anda, gunakan nomor versi itu untuk memberi tahu mereka. + +Tentang +------- + +Spesifikasi Pemversian Semantik dibuat oleh [Tom Preston-Werner](http://tom.preston-werner.com), pembuat Gravatars dan *cofounder* dari GitHub. + +Terjemahan Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com), [Christian B. Wibowo](https://github.com/cwibowo), dan [Hans5958](https://github.com/Hans5958). + +Untuk saran dan kritik, silahkan [buka issue di GitHub](https://github.com/mojombo/semver/issues). diff --git a/lang/id/spec/v1.0.0-beta.md b/lang/id/spec/v1.0.0-beta.md new file mode 100644 index 00000000..1e65306c --- /dev/null +++ b/lang/id/spec/v1.0.0-beta.md @@ -0,0 +1,106 @@ +--- +title: Pemversian Semantik 1.0.0-beta +language: id +--- + +Pemversian Semantik 1.0.0-beta +============================== + +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 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 berasumsi versi mana yang bisa digunakan dengan versi yang lain. *Dependency hell* adalah saat Anda berada pada satu atau dua masalah ini, yang menahan Anda untuk bergerak maju dengan aman dan mudah. + +Sebagai solusi permasalahan ini, saya mengusulkan seperangkat aturan dan persayaratan sederhana yang menentukan bagaimana nomor versi diberikan dan bertambah. Agar sistem ini dapat bekerja, Anda harus mengumumkan API publik terlebih dahulu. Ini dapat terdiri dari dokumentasi atau diberlakukan oleh kode itu sendiri. Apapun itu, API ini harus jelas dan tepat. Setelah Anda mengidentifikasi API publik Anda, Anda mengomunikasikan perubahan pada API tersebut dengan penambahan spesifik pada nomor versi Anda. Pertimbangkan format versi X.Y.Z (Major.Minor.Patch). Perbaikan bug yang tidak memengaruhi API tersebut akan menambah versi *patch*, penambahan/perubahan API yang kompatibel dengan versi sebelumnya akan menambah versi *minor*, dan perubahan API yang tidak kompatibel dengan versi sebelumnya akan menambah versi major. + +Standar ini bernama "Pemversian Semantik". Dengan skema ini, setiap orang yang melihat angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut. + +Spesifikasi Pemversian Semantik (SemVer) +---------------------------------------- + +Kata/frasa "HARUS" ("MUST"), "TIDAK BOLEH" ("MUST NOT"), "DIBUTUHKAN" ("REQUIRED"), "SEHARUSNYA" ("SHALL"), "JANGAN SAMPAI" ("SHALL NOT"), "SEBAIKNYA" ("SHOULD"), "SEBAIKNYA TIDAK" ("SHOULD NOT"), "DIREKOMENDASIKAN" ("RECOMMENDED"), "BISA" ("MAY") , dan "OPSIONAL" di dokumen ini sesuai dengan RFC 2119. + +1. Perangkat lunak dengan Pemversian Semantik HARUS menentukan API public. Bisa dijelaskan dengan kode, atau ditulis di dokumentasi saja. Apapun itu harus ditulis dengan jelas dan akurat. + +1. Versi normal HARUS ditulis dalam bentuk X.Y.Z, dengan X, Y, dan Z adalah bilangan bulat. X adalah versi *major*, Y adalah *minor*, dan Z adalah *patch*. Setiap elemen HARUS bertambah secara numerik dengan kenaikan sebesar satu. Contohnya: 1.9.0 -> 1.10.0 -> 1.11.0 + +1. Ketika nomor versi *major* bertambah, versi *minor* dan *patch* versi HARUS diatur ulang ke nol. Ketika nomor versi *minor* bertambah, nomor versi *patch* HARUS disetel ulang ke nol. Misalnya: 1.1.3 -> 2.0.0 dan 2.1.7 -> +2.2.0. + +1. Versi prarilis BISA ditulis dengan menambahkan titik dan rangkaian pengenal dengan pemisah titik tepat setelah versi *patch*. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda pisah [0-9A-Za-z] dan HARUS mulai dengan sebuah huruf [A-Za-z]. Versi prarilis diperbolehkan, namun memiliki presendens yang lebih rendah dibandingkan dengan versi normal. Presedens SEBAIKNYA ditentukan dari urutan leksikografik ASCII. Contoh: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92. + +1. Setelah sebuah paket berversi dirilis, isi dari versi tersebut TIDAK BOLEH diubah. Setiap perubahan harus dirilis sebagai versi baru. + +1. Versi *major* 0 (0.y.z) adalah untuk pengembangan awal. Apapun bisa bisa berubah kapanpun. API publik sebaiknya dianggap tidak stabil di versi ini. + +1. Versi 1.0.0 adalah titik awal API publik. Cara nomor versi ini dinaikkan setelah rilis ini adalah tergantung dengan API publik ini dan bagaimana ia berubah. + +1. Versi *patch* Z (x.y.Z \| x > 0) HARUS dinaikkan jika ada perbaikan bug yang kompatibel dengan versi lama. Sebuah perbaikan bug didefinisikan sebagai perubahan internal yang memperbaiki perilaku yang salah. + +1. Versi *minor* Y (x.Y.z \| x > 0) HARUS dinaikkan jika ada fitur baru yang kompatibel dengan versi lama dalam API publik. Ini BISA dinaikkan jika ada tambahan fungsionalitas substansial atau terjadi peningkatan di dalam kode privat. Ini BISA diubah bersama dengan perubahan tingkat *patch*. + +1. Versi *major* X (X.y.z \| X > 0) HARUS dinaikkan jika ada perubahan yang membuat versi baru tidak kompatibel dengan versi lama pada API publik. Ini BISA diubah bersama dengan perubahan tingkat *patch* dan *minor*. + +Spesifikasi Penandaan (SemVerTag) +--------------------------------- + +Subspesifikasi ini SEBAIKNYA digunakan jika Anda menggunakan sistem kontrol versi (Git, Mercurial, SVN, dll) untuk menyimpan kode Anda. Dengan menggunaakan sistem ini, alat otomatis dapat memeriksa paket Anda dan menentukan kepatuhan SemVer dan versi yang dirilis. + +1. Saat menandai rilis dalam sistem kontrol versi, *tag* untuk sebuah versi HARUS "vX.Y.Z", seperti "v3.1.0". + +1. Revisi pertama yang memperkenalkan kepatuhan SemVer SEBAIKNYA diberi *tag* "semver". Hal ini memungkinkan proyek yang sudah ada sebelumnya untuk mengasumsikan kepatuhan pada suatu titik dan agar alat otomatis tahu tentang hal ini. + +Kenapa Menggunakan Pemversian Semantik? +--------------------------------------- + +Ini bukanlah ide baru yang revolusioner. Faktanya, kalian mungkin sudah menggunakan standar ini, hanya saja tidak terlalu ketat. Masalahnya, "tidak teralu ketat" saja tidak cukup bagus. Tanpa kepatuhan terhadap beberapa jenis spesifikasi formal, nomor versi adalah pada dasarnya tidak berguna untuk manajemen dependensi. Dengan memberikan nama dan definisi yang jelas definisi yang jelas untuk ide-ide tersebut, mengkomunikasikan maksud Anda kepada pengguna perangkat lunak Anda menjadi lebih mudah. Setelah maksud ini jelas, spesifikasi ketergantungan yang fleksibel (tetapi tidak terlalu fleksibel) akhirnya dapat dibuat. + +Contoh sederhana ini menunjukkan manfaat Pemversian 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 Pemversian Semantik, "MobilPemadamKebakaran" bisa dengan yakin menggunakan modul "Tangga" selama modul tersebut mempunyai versi antara 3.1.0 sampai dengan sebelum versi 4.0.0. + +Sebagai pengembang yang bertanggung jawab, tentu saja Anda ingin memverifikasi bahwa peningkatan paket berfungsi seperti yang diiklankan. Dunia nyata tidaklah pasti; tidak ada yang bisa kita lakukan selain waspada. Yang bisa Anda lakukan adalah membiarkan Pemversian Semantik memberi Anda cara yang masuk akal untuk merilis dan memutakhirkan paket tanpa harus menggulirkan versi baru dari paket dependen, membuat Anda menghemat waktu dan kerumitan. + +Jika menurut kalian aturan ini bagus, cara untuk memulai menggunakan pemversian semantik adalah dengan menautkan situs ini dalam README kalian supaya orang lain bisa tahu mengenai aturan ini dan mulai menggunakannya juga. + +Pertanyaan Yang Sering Diajukan +------------------------------- + +### Bagaimana saya tahu kapan merilis 1.0.0? + +Jika perangkat lunak Anda digunakan dalam produksi, mungkin perangkat lunak Anda sudah versi 1.0.0. Jika Anda memiliki API yang stabil yang menjadi andalan pengguna, Anda harusnya sudah pada 1.0.0. Jika Anda sangat mengkhawatirkan kompatibilitas versi lama, Anda mungkin sudah pada 1.0.0. + +### Bukankah standar ini mencegah perkembangan yang cepat? + +Versi *major* nol adalah tentang pengembangan yang cepat. Jika Anda mengubah API setiap hari, Anda harus tetap berada di versi 0.x.x atau di pengembangan terpisah yang bekerja pada versi *major* berikutnya. + +### Jika perubahan terkecil yang tidak kompatibel dengan API publik memerlukan kenaikkan versi *major*, bukankah saya akan berakhir di versi 42.0.0 dengan sangat cepat? + +Ini adalah pertanyaan tentang pengembangan yang bertanggung jawab dan pandangan ke depan. Perubahan yang tidak kompatibel tidak boleh diperkenalkan dengan mudah ke perangkat lunak yang memiliki banyak kode dependen. Biaya yang harus dikeluarkan untuk meng-upgrade bisa sangat besar. Kewajiban mengganti versi *major* untuk merilis perubahan yang tidak kompatibel seharusnya membuat Anda memikirkan dampak dari perubahan Anda, dan mengevaluasi perbandingan biaya dan manfaat yang terkait. + +### Mendokumentasikan seluruh API publik sangatlah merepotkan! + +Sudah tanggung jawab Anda sebagai pengembang profesional untuk mendokumentasikan perangkat lunak untuk digunakan oleh orang lain dengan benar. Mengelola kompleksitas perangkat lunak adalah bagian yang sangat penting dalam menjaga proyek tetap efisien, dan itu sulit dilakukan jika tidak ada yang tahu cara menggunakan perangkat lunak Anda, atau metode apa yang aman untuk dihubungi. Dalam jangka panjang, Pemversian Semantik, dan desakan pada API publik yang terdefinisi dengan baik dapat membuat semua orang dan segala sesuatu berjalan dengan lancar. + +### Bagaimana jika secara tidak sengaja membuat perubahan yang menjadikan versi lama tidak bisa dipakai? + +Setelah Anda menyadari bahwa Anda telah melanggar spesifikasi Pemversian Semantik, perbaiki dan rilis versi *minor* baru yang memperbaiki masalah dan mengembalikan kompatibilitas versi lama. Ingat, memodifikasi rilis yang telah diberi versi adalah dilarang, bahkan dalam kondisi ini. Jika mau, dokumentasikan versi yang bermasalah dan memberi tahu pengguna Anda tentang masalah tersebut sehingga mereka mengetahui versi yang bermasalah. + +### Apa yang harus saya lakukan jika saya memperbarui dependensi saya sendiri tanpa mengubah API publik? + +Hal tersebut dianggap kompatibel karena tidak mempengaruhi API publik. Perangkat lunak yang secara eksplisit bergantung pada dependensi yang sama dengan paket Anda harus memiliki spesifikasi dependensi mereka sendiri dan pembuatnya akan memberi tahu konflik yang ada. Menentukan apakah perubahan tersebut merupakan tingkat *patch* atau tingkat *minor* tergantung pada apakah Anda memperbarui dependensi untuk memperbaiki *bug* atau memperkenalkan fungsionalitas baru. Saya biasanya mengharapkan kode tambahan untuk contoh yang kedua, yang dalam hal ini jelas merupakan kenaikan tingkat *minor*. + +### Apa yang harus saya lakukan jika bug yang sedang diperbaiki mengembalikan kode agar sesuai dengan API publik (misalnya, kode tidak sinkron dengan dokumentasi API publik)? + +Gunakan kebijakan terbaik Anda. Jika Anda memiliki audiens yang sangat besar yang akan terpengaruh secara drastis dengan apa yang dimaksudkan oleh API publik, maka lebih baik melakukan rilis versi *major*, meskipun perbaikannya dapat sangat dianggap sebagai rilis *patch*. Ingat, Pemversian Semantik adalah segalanya tentang menyampaikan makna melalui perubahan nomor versi. Jika perubahan ini perubahan ini penting bagi pengguna Anda, gunakan nomor versi itu untuk memberi tahu mereka. + +Tentang +------- + +Spesifikasi Pemversian Semantik dibuat oleh [Tom Preston-Werner](http://tom.preston-werner.com), pembuat Gravatars dan *cofounder* dari GitHub. + +Terjemahan Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com), [Christian B. Wibowo](https://github.com/cwibowo), dan [Hans5958](https://github.com/Hans5958). + +Untuk saran dan kritik, silahkan [buka issue di GitHub](https://github.com/mojombo/semver/issues). + +Lisensi +------- + +[Creative Commons ― CC BY 3.0](http://creativecommons.org/licenses/by/3.0/) diff --git a/lang/id/spec/v1.0.0.md b/lang/id/spec/v1.0.0.md new file mode 100644 index 00000000..ebcf6507 --- /dev/null +++ b/lang/id/spec/v1.0.0.md @@ -0,0 +1,110 @@ +--- +title: Pemversian Semantik 1.0.0 +language: id +--- + +Pemversian Semantik 1.0.0 +========================= + +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 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 berasumsi versi mana yang bisa digunakan dengan versi yang lain. *Dependency hell* adalah saat Anda berada pada satu atau dua masalah ini, yang menahan Anda untuk bergerak maju dengan aman dan mudah. + +Sebagai solusi permasalahan ini, saya mengusulkan seperangkat aturan dan persayaratan sederhana yang menentukan bagaimana nomor versi diberikan dan bertambah. Agar sistem ini dapat bekerja, Anda harus mengumumkan API publik terlebih dahulu. Ini dapat terdiri dari dokumentasi atau diberlakukan oleh kode itu sendiri. Apapun itu, API ini harus jelas dan tepat. Setelah Anda mengidentifikasi API publik Anda, Anda mengomunikasikan perubahan pada API tersebut dengan penambahan spesifik pada nomor versi Anda. Pertimbangkan format versi X.Y.Z (Major.Minor.Patch). Perbaikan bug yang tidak memengaruhi API tersebut akan menambah versi *patch*, penambahan/perubahan API yang kompatibel dengan versi sebelumnya akan menambah versi *minor*, dan perubahan API yang tidak kompatibel dengan versi sebelumnya akan menambah versi major. + +Standar ini bernama "Pemversian Semantik". Dengan skema ini, setiap orang yang melihat angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut. + +Spesifikasi Pemversian Semantik (SemVer) +---------------------------------------- + +Kata/frasa "HARUS" ("MUST"), "TIDAK BOLEH" ("MUST NOT"), "DIBUTUHKAN" ("REQUIRED"), "SEHARUSNYA" ("SHALL"), "JANGAN SAMPAI" ("SHALL NOT"), "SEBAIKNYA" ("SHOULD"), "SEBAIKNYA TIDAK" ("SHOULD NOT"), "DIREKOMENDASIKAN" ("RECOMMENDED"), "BISA" ("MAY") , dan "OPSIONAL" di dokumen ini sesuai dengan RFC 2119. + +1. Perangkat lunak dengan Pemversian Semantik HARUS menentukan API public. Bisa dijelaskan dengan kode, atau ditulis di dokumentasi saja. Apapun itu harus ditulis dengan jelas dan akurat. + +1. Versi normal HARUS ditulis dalam bentuk X.Y.Z, dengan X, Y, dan Z adalah bilangan bulat. X adalah versi *major*, Y adalah *minor*, dan Z adalah *patch*. Setiap elemen HARUS bertambah secara numerik dengan kenaikan sebesar satu. Contohnya: 1.9.0 -> 1.10.0 -> 1.11.0 + +1. Ketika nomor versi *major* bertambah, versi *minor* dan *patch* versi HARUS diatur ulang ke nol. Ketika nomor versi *minor* bertambah, nomor versi *patch* HARUS disetel ulang ke nol. Misalnya: 1.1.3 -> 2.0.0 dan 2.1.7 -> +2.2.0. + +1. Versi prarilis BISA ditulis dengan menambahkan tanda pisah dan rangkaian pengenal dengan pemisah titik tepat setelah versi *patch*. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda pisah [0-9A-Za-z]. Versi prarilis diperbolehkan, namun memiliki presendens yang lebih rendah dibandingkan dengan versi normal. Presedens SEBAIKNYA ditentukan dari urutan leksikografik ASCII. Contoh: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92. + +1. Setelah sebuah paket berversi dirilis, isi dari versi tersebut TIDAK BOLEH diubah. Setiap perubahan harus dirilis sebagai versi baru. + +1. Versi *major* 0 (0.y.z) adalah untuk pengembangan awal. Apapun bisa bisa berubah kapanpun. API publik sebaiknya dianggap tidak stabil di versi ini. + +1. Versi 1.0.0 adalah titik awal API publik. Cara nomor versi ini dinaikkan setelah rilis ini adalah tergantung dengan API publik ini dan bagaimana ia berubah. + +1. Versi *patch* Z (x.y.Z \| x > 0) HARUS dinaikkan jika ada perbaikan bug yang kompatibel dengan versi lama. Sebuah perbaikan bug didefinisikan sebagai perubahan internal yang memperbaiki perilaku yang salah. + +1. Versi *minor* Y (x.Y.z \| x > 0) HARUS dinaikkan jika ada fitur baru yang kompatibel dengan versi lama dalam API publik. Ini BISA dinaikkan jika ada tambahan fungsionalitas substansial atau terjadi peningkatan di dalam kode privat. Ini BISA diubah bersama dengan perubahan tingkat *patch*. Versi *patch* HARUS dikembalikan ke angka 0 jika versi *minor* dinaikkan. + +1. Versi *major* X (X.y.z \| X > 0) HARUS dinaikkan jika ada perubahan yang membuat versi baru tidak kompatibel dengan versi lama pada API publik. Ini BISA diubah bersama dengan perubahan tingkat *patch* dan *minor*. Versi *minor* dan *patch* HARUS dikembalikan ke angka 0 jika versi *major* dinaikkan. + +Spesifikasi Penandaan (SemVerTag) +--------------------------------- + +Subspesifikasi ini SEBAIKNYA digunakan jika Anda menggunakan sistem kontrol versi (Git, Mercurial, SVN, dll) untuk menyimpan kode Anda. Dengan menggunaakan sistem ini, alat otomatis dapat memeriksa paket Anda dan menentukan kepatuhan SemVer dan versi yang dirilis. + +1. Saat menandai rilis dalam sistem kontrol versi, *tag* untuk sebuah versi HARUS "vX.Y.Z", seperti "v3.1.0". + +1. Revisi pertama yang memperkenalkan kepatuhan SemVer SEBAIKNYA diberi *tag* "semver". Hal ini memungkinkan proyek yang sudah ada sebelumnya untuk mengasumsikan kepatuhan pada suatu titik dan agar alat otomatis tahu tentang hal ini. + +Kenapa Menggunakan Pemversian Semantik? +--------------------------------------- + +Ini bukanlah ide baru yang revolusioner. Faktanya, kalian mungkin sudah menggunakan standar ini, hanya saja tidak terlalu ketat. Masalahnya, "tidak teralu ketat" saja tidak cukup bagus. Tanpa kepatuhan terhadap beberapa jenis spesifikasi formal, nomor versi adalah pada dasarnya tidak berguna untuk manajemen dependensi. Dengan memberikan nama dan definisi yang jelas definisi yang jelas untuk ide-ide tersebut, mengkomunikasikan maksud Anda kepada pengguna perangkat lunak Anda menjadi lebih mudah. Setelah maksud ini jelas, spesifikasi ketergantungan yang fleksibel (tetapi tidak terlalu fleksibel) akhirnya dapat dibuat. + +Contoh sederhana ini menunjukkan manfaat Pemversian 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 Pemversian Semantik, "MobilPemadamKebakaran" bisa dengan yakin menggunakan modul "Tangga" selama modul tersebut mempunyai versi antara 3.1.0 sampai dengan sebelum versi 4.0.0. + +Sebagai pengembang yang bertanggung jawab, tentu saja Anda ingin memverifikasi bahwa peningkatan paket berfungsi seperti yang diiklankan. Dunia nyata tidaklah pasti; tidak ada yang bisa kita lakukan selain waspada. Yang bisa Anda lakukan adalah membiarkan Pemversian Semantik memberi Anda cara yang masuk akal untuk merilis dan memutakhirkan paket tanpa harus menggulirkan versi baru dari paket dependen, membuat Anda menghemat waktu dan kerumitan. + +Jika menurut kalian aturan ini bagus, cara untuk memulai menggunakan pemversian semantik adalah dengan menautkan situs ini dalam README kalian supaya orang lain bisa tahu mengenai aturan ini dan mulai menggunakannya juga. + +Pertanyaan Yang Sering Diajukan +------------------------------- + +### Bagaimana cara menangani revisi dalam fase pengembangan awal 0.y.z? + +Hal yang paling sederhana untuk dilakukan adalah memulai rilis pengembangan awal Anda pada 0.1.0 dan kemudian meningkatkan versi minor untuk setiap rilis berikutnya. + +### Bagaimana saya tahu kapan merilis 1.0.0? + +Jika perangkat lunak Anda digunakan dalam produksi, mungkin perangkat lunak Anda sudah versi 1.0.0. Jika Anda memiliki API yang stabil yang menjadi andalan pengguna, Anda harusnya sudah pada 1.0.0. Jika Anda sangat mengkhawatirkan kompatibilitas versi lama, Anda mungkin sudah pada 1.0.0. + +### Bukankah standar ini mencegah perkembangan yang cepat? + +Versi *major* nol adalah tentang pengembangan yang cepat. Jika Anda mengubah API setiap hari, Anda harus tetap berada di versi 0.x.x atau di pengembangan terpisah yang bekerja pada versi *major* berikutnya. + +### Jika perubahan terkecil yang tidak kompatibel dengan API publik memerlukan kenaikkan versi *major*, bukankah saya akan berakhir di versi 42.0.0 dengan sangat cepat? + +Ini adalah pertanyaan tentang pengembangan yang bertanggung jawab dan pandangan ke depan. Perubahan yang tidak kompatibel tidak boleh diperkenalkan dengan mudah ke perangkat lunak yang memiliki banyak kode dependen. Biaya yang harus dikeluarkan untuk meng-upgrade bisa sangat besar. Kewajiban mengganti versi *major* untuk merilis perubahan yang tidak kompatibel seharusnya membuat Anda memikirkan dampak dari perubahan Anda, dan mengevaluasi perbandingan biaya dan manfaat yang terkait. + +### Mendokumentasikan seluruh API publik sangatlah merepotkan! + +Sudah tanggung jawab Anda sebagai pengembang profesional untuk mendokumentasikan perangkat lunak untuk digunakan oleh orang lain dengan benar. Mengelola kompleksitas perangkat lunak adalah bagian yang sangat penting dalam menjaga proyek tetap efisien, dan itu sulit dilakukan jika tidak ada yang tahu cara menggunakan perangkat lunak Anda, atau metode apa yang aman untuk dihubungi. Dalam jangka panjang, Pemversian Semantik, dan desakan pada API publik yang terdefinisi dengan baik dapat membuat semua orang dan segala sesuatu berjalan dengan lancar. + +### Bagaimana jika secara tidak sengaja membuat perubahan yang menjadikan versi lama tidak bisa dipakai? + +Setelah Anda menyadari bahwa Anda telah melanggar spesifikasi Pemversian Semantik, perbaiki dan rilis versi *minor* baru yang memperbaiki masalah dan mengembalikan kompatibilitas versi lama. Ingat, memodifikasi rilis yang telah diberi versi adalah dilarang, bahkan dalam kondisi ini. Jika mau, dokumentasikan versi yang bermasalah dan memberi tahu pengguna Anda tentang masalah tersebut sehingga mereka mengetahui versi yang bermasalah. + +### Apa yang harus saya lakukan jika saya memperbarui dependensi saya sendiri tanpa mengubah API publik? + +Hal tersebut dianggap kompatibel karena tidak mempengaruhi API publik. Perangkat lunak yang secara eksplisit bergantung pada dependensi yang sama dengan paket Anda harus memiliki spesifikasi dependensi mereka sendiri dan pembuatnya akan memberi tahu konflik yang ada. Menentukan apakah perubahan tersebut merupakan tingkat *patch* atau tingkat *minor* tergantung pada apakah Anda memperbarui dependensi untuk memperbaiki *bug* atau memperkenalkan fungsionalitas baru. Saya biasanya mengharapkan kode tambahan untuk contoh yang kedua, yang dalam hal ini jelas merupakan kenaikan tingkat *minor*. + +### Apa yang harus saya lakukan jika bug yang sedang diperbaiki mengembalikan kode agar sesuai dengan API publik (misalnya, kode tidak sinkron dengan dokumentasi API publik)? + +Gunakan kebijakan terbaik Anda. Jika Anda memiliki audiens yang sangat besar yang akan terpengaruh secara drastis dengan apa yang dimaksudkan oleh API publik, maka lebih baik melakukan rilis versi *major*, meskipun perbaikannya dapat sangat dianggap sebagai rilis *patch*. Ingat, Pemversian Semantik adalah segalanya tentang menyampaikan makna melalui perubahan nomor versi. Jika perubahan ini perubahan ini penting bagi pengguna Anda, gunakan nomor versi itu untuk memberi tahu mereka. + +Tentang +------- + +Spesifikasi Pemversian Semantik dibuat oleh [Tom Preston-Werner](http://tom.preston-werner.com), pembuat Gravatars dan *cofounder* dari GitHub. + +Terjemahan Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com), [Christian B. Wibowo](https://github.com/cwibowo), dan [Hans5958](https://github.com/Hans5958). + +Untuk saran dan kritik, silahkan [buka issue di GitHub](https://github.com/mojombo/semver/issues). + +Lisensi +------- + +[Creative Commons ― CC BY 3.0](http://creativecommons.org/licenses/by/3.0/) diff --git a/lang/id/spec/v2.0.0-rc.1.md b/lang/id/spec/v2.0.0-rc.1.md new file mode 100644 index 00000000..e226681c --- /dev/null +++ b/lang/id/spec/v2.0.0-rc.1.md @@ -0,0 +1,109 @@ +--- +title: Pemversian Semantik 2.0.0-rc-1 +language: id +--- + +Pemversian Semantik 2.0.0-rc.1 +============================== + +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 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 berasumsi versi mana yang bisa digunakan dengan versi yang lain. *Dependency hell* adalah saat Anda berada pada satu atau dua masalah ini, yang menahan Anda untuk bergerak maju dengan aman dan mudah. + +Sebagai solusi permasalahan ini, saya mengusulkan seperangkat aturan dan persayaratan sederhana yang menentukan bagaimana nomor versi diberikan dan bertambah. Agar sistem ini dapat bekerja, Anda harus mengumumkan API publik terlebih dahulu. Ini dapat terdiri dari dokumentasi atau diberlakukan oleh kode itu sendiri. Apapun itu, API ini harus jelas dan tepat. Setelah Anda mengidentifikasi API publik Anda, Anda mengomunikasikan perubahan pada API tersebut dengan penambahan spesifik pada nomor versi Anda. Pertimbangkan format versi X.Y.Z (Major.Minor.Patch). Perbaikan bug yang tidak memengaruhi API tersebut akan menambah versi *patch*, penambahan/perubahan API yang kompatibel dengan versi sebelumnya akan menambah versi *minor*, dan perubahan API yang tidak kompatibel dengan versi sebelumnya akan menambah versi major. + +Standar ini bernama "Pemversian Semantik". Dengan skema ini, setiap orang yang melihat angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut. + +Spesifikasi Pemversian Semantik (SemVer) +---------------------------------------- + +Kata/frasa "HARUS" ("MUST"), "TIDAK BOLEH" ("MUST NOT"), "DIBUTUHKAN" ("REQUIRED"), "SEHARUSNYA" ("SHALL"), "JANGAN SAMPAI" ("SHALL NOT"), "SEBAIKNYA" ("SHOULD"), "SEBAIKNYA TIDAK" ("SHOULD NOT"), "DIREKOMENDASIKAN" ("RECOMMENDED"), "BISA" ("MAY") di dokumen ini sesuai dengan RFC 2119. + +1. Perangkat lunak dengan Pemversian Semantik HARUS menentukan API public. Bisa dijelaskan dengan kode, atau ditulis di dokumentasi saja. Apapun itu harus ditulis dengan jelas dan akurat. + +1. Versi normal HARUS ditulis dalam bentuk X.Y.Z, dengan X, Y, dan Z adalah bilangan bulat nonnegatif. X adalah versi *major*, Y adalah *minor*, dan Z adalah *patch*. Setiap elemen HARUS bertambah secara numerik dengan kenaikan sebesar satu. Contohnya: 1.9.0 -> 1.10.0 -> 1.11.0 + +1. Ketika nomor versi *major* bertambah, versi *minor* dan *patch* versi HARUS diatur ulang ke nol. Ketika nomor versi *minor* bertambah, nomor versi *patch* HARUS disetel ulang ke nol. Misalnya: 1.1.3 -> 2.0.0 dan 2.1.7 -> +2.2.0. + +1. Setelah sebuah paket berversi dirilis, isi dari versi tersebut TIDAK BOLEH diubah. Setiap perubahan harus dirilis sebagai versi baru. + +1. Versi *major* 0 (0.y.z) adalah untuk pengembangan awal. Apapun bisa bisa berubah kapanpun. API publik sebaiknya dianggap tidak stabil di versi ini. + +1. Versi 1.0.0 adalah titik awal API publik. Cara nomor versi ini dinaikkan setelah rilis ini adalah tergantung dengan API publik ini dan bagaimana ia berubah. + +1. Versi *patch* Z (x.y.Z \| x > 0) HARUS dinaikkan jika ada perbaikan bug yang kompatibel dengan versi lama. Sebuah perbaikan bug didefinisikan sebagai perubahan internal yang memperbaiki perilaku yang salah. + +1. Versi *minor* Y (x.Y.z \| x > 0) HARUS dinaikkan jika ada fitur baru yang kompatibel dengan versi lama dalam API publik. Ini HARUS dinaikkan jika sebuah fungsionalitas API publik dibuat usang. Ini BISA dinaikkan jika ada tambahan fungsionalitas substansial atau terjadi peningkatan di dalam kode privat. Ini BISA diubah bersama dengan perubahan tingkat *patch*. Versi *patch* HARUS dikembalikan ke angka 0 jika versi *minor* dinaikkan. + +1. Versi *major* X (X.y.z \| X > 0) HARUS dinaikkan jika ada perubahan yang membuat versi baru tidak kompatibel dengan versi lama pada API publik. Ini BISA diubah bersama dengan perubahan tingkat *patch* dan *minor*. Versi *minor* dan *patch* HARUS dikembalikan ke angka 0 jika versi *major* dinaikkan. + +1. Versi prarilis BISA ditulis dengan menambahkan tanda pisah dan rangkaian pengenal dengan pemisah titik tepat setelah versi *patch*. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda pisah [0-9A-Za-z]. Versi prarilis diperbolehkan, namun memiliki presendens yang lebih rendah dibandingkan dengan versi normal. Contoh: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92. + +1. Sebuah versi *build* BISA ditulis didahului dengan tanda tambah dan rangkaian pengenal dengan pemisah titik setelah versi *patch* atau prarilis. Versi *build* HARUS ditulis dengan huruf ASCII alfanumerik dan tanda pisah [0-9A-Za-z]. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda pisah [0-9A-Za-z]. Versi *build* dapat digunakan dan memiliki presedens lebih tinggi dibandingkan versi normal yang terkait. Contoh: 1.0.0+build.1, 1.3.7+build.11.e0f985a. + +1. Presedens HARUS dihitung dengan memisahkan versi menjadi pengenal *major*, *minor*, *patch*, prarilis, dan pengenal *build* dalam urutan tersebut. Presedens prarilis dan pengenal *build* HARUS ditentukan dengan membandingkan setiap pengenal yang dipisahkan titik sebagai berikut: pengenal yang hanya terdiri dari angka dibandingkan secara numerik dan pengenal dengan huruf atau tanda pisah dibandingkan secara leksikal dalam urutan pengurutan ASCII. Pengenal numerik selalu memiliki prioritas yang lebih rendah daripada pengenal non-numerik. Contoh: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a. + +Kenapa Menggunakan Pemversian Semantik? +--------------------------------------- + +Ini bukanlah ide baru yang revolusioner. Faktanya, kalian mungkin sudah menggunakan standar ini, hanya saja tidak terlalu ketat. Masalahnya, "tidak teralu ketat" saja tidak cukup bagus. Tanpa kepatuhan terhadap beberapa jenis spesifikasi formal, nomor versi adalah pada dasarnya tidak berguna untuk manajemen dependensi. Dengan memberikan nama dan definisi yang jelas definisi yang jelas untuk ide-ide tersebut, mengkomunikasikan maksud Anda kepada pengguna perangkat lunak Anda menjadi lebih mudah. Setelah maksud ini jelas, spesifikasi ketergantungan yang fleksibel (tetapi tidak terlalu fleksibel) akhirnya dapat dibuat. + +Contoh sederhana ini menunjukkan manfaat Pemversian 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 Pemversian Semantik, "MobilPemadamKebakaran" bisa dengan yakin menggunakan modul "Tangga" selama modul tersebut mempunyai versi antara 3.1.0 sampai dengan sebelum versi 4.0.0. + +Sebagai pengembang yang bertanggung jawab, tentu saja Anda ingin memverifikasi bahwa peningkatan paket berfungsi seperti yang diiklankan. Dunia nyata tidaklah pasti; tidak ada yang bisa kita lakukan selain waspada. Yang bisa Anda lakukan adalah membiarkan Pemversian Semantik memberi Anda cara yang masuk akal untuk merilis dan memutakhirkan paket tanpa harus menggulirkan versi baru dari paket dependen, membuat Anda menghemat waktu dan kerumitan. + +Jika menurut kalian aturan ini bagus, cara untuk memulai menggunakan pemversian semantik adalah dengan menautkan situs ini dalam README kalian supaya orang lain bisa tahu mengenai aturan ini dan mulai menggunakannya juga. + +Pertanyaan Yang Sering Diajukan +------------------------------- + +### Bagaimana cara menangani revisi dalam fase pengembangan awal 0.y.z? + +Hal yang paling sederhana untuk dilakukan adalah memulai rilis pengembangan awal Anda pada 0.1.0 dan kemudian meningkatkan versi minor untuk setiap rilis berikutnya. + +### Bagaimana saya tahu kapan merilis 1.0.0? + +Jika perangkat lunak Anda digunakan dalam produksi, mungkin perangkat lunak Anda sudah versi 1.0.0. Jika Anda memiliki API yang stabil yang menjadi andalan pengguna, Anda harusnya sudah pada 1.0.0. Jika Anda sangat mengkhawatirkan kompatibilitas versi lama, Anda mungkin sudah pada 1.0.0. + +### Bukankah standar ini mencegah perkembangan yang cepat? + +Versi *major* nol adalah tentang pengembangan yang cepat. Jika Anda mengubah API setiap hari, Anda harus tetap berada di versi 0.x.x atau di pengembangan terpisah yang bekerja pada versi *major* berikutnya. + +### Jika perubahan terkecil yang tidak kompatibel dengan API publik memerlukan kenaikkan versi *major*, bukankah saya akan berakhir di versi 42.0.0 dengan sangat cepat? + +Ini adalah pertanyaan tentang pengembangan yang bertanggung jawab dan pandangan ke depan. Perubahan yang tidak kompatibel tidak boleh diperkenalkan dengan mudah ke perangkat lunak yang memiliki banyak kode dependen. Biaya yang harus dikeluarkan untuk meng-upgrade bisa sangat besar. Kewajiban mengganti versi *major* untuk merilis perubahan yang tidak kompatibel seharusnya membuat Anda memikirkan dampak dari perubahan Anda, dan mengevaluasi perbandingan biaya dan manfaat yang terkait. + +### Mendokumentasikan seluruh API publik sangatlah merepotkan! + +Sudah tanggung jawab Anda sebagai pengembang profesional untuk mendokumentasikan perangkat lunak untuk digunakan oleh orang lain dengan benar. Mengelola kompleksitas perangkat lunak adalah bagian yang sangat penting dalam menjaga proyek tetap efisien, dan itu sulit dilakukan jika tidak ada yang tahu cara menggunakan perangkat lunak Anda, atau metode apa yang aman untuk dihubungi. Dalam jangka panjang, Pemversian Semantik, dan desakan pada API publik yang terdefinisi dengan baik dapat membuat semua orang dan segala sesuatu berjalan dengan lancar. + +### Bagaimana jika secara tidak sengaja membuat perubahan yang menjadikan versi lama tidak bisa dipakai? + +Setelah Anda menyadari bahwa Anda telah melanggar spesifikasi Pemversian Semantik, perbaiki dan rilis versi *minor* baru yang memperbaiki masalah dan mengembalikan kompatibilitas versi lama. Ingat, memodifikasi rilis yang telah diberi versi adalah dilarang, bahkan dalam kondisi ini. Jika mau, dokumentasikan versi yang bermasalah dan memberi tahu pengguna Anda tentang masalah tersebut sehingga mereka mengetahui versi yang bermasalah. + +### Apa yang harus saya lakukan jika saya memperbarui dependensi saya sendiri tanpa mengubah API publik? + +Hal tersebut dianggap kompatibel karena tidak mempengaruhi API publik. Perangkat lunak yang secara eksplisit bergantung pada dependensi yang sama dengan paket Anda harus memiliki spesifikasi dependensi mereka sendiri dan pembuatnya akan memberi tahu konflik yang ada. Menentukan apakah perubahan tersebut merupakan tingkat *patch* atau tingkat *minor* tergantung pada apakah Anda memperbarui dependensi untuk memperbaiki *bug* atau memperkenalkan fungsionalitas baru. Saya biasanya mengharapkan kode tambahan untuk contoh yang kedua, yang dalam hal ini jelas merupakan kenaikan tingkat *minor*. + +### Apa yang harus saya lakukan jika bug yang sedang diperbaiki mengembalikan kode agar sesuai dengan API publik (misalnya, kode tidak sinkron dengan dokumentasi API publik)? + +Gunakan kebijakan terbaik Anda. Jika Anda memiliki audiens yang sangat besar yang akan terpengaruh secara drastis dengan apa yang dimaksudkan oleh API publik, maka lebih baik melakukan rilis versi *major*, meskipun perbaikannya dapat sangat dianggap sebagai rilis *patch*. Ingat, Pemversian Semantik adalah segalanya tentang menyampaikan makna melalui perubahan nomor versi. Jika perubahan ini perubahan ini penting bagi pengguna Anda, gunakan nomor versi itu untuk memberi tahu mereka. + +### Bagaimana cara menangani fungsionalitas yang sudah diusangkan? + +Mengusangkan fungsionalitas yang ada adalah hal yang lumrah dalam pengembangan perangkat lunak dan sering kali diperlukan untuk membuat suatu kemajuan. Ketika Anda mengusangkan bagian dari API publik Anda, Anda harus melakukan dua hal: (1) memperbarui dokumentasi Anda untuk memberi tahu pengguna tahu tentang perubahan tersebut, dan (2) mengeluarkan rilis minor baru dengan penghentian yang baru dengan pengusangan itu dibuat. Sebelum Anda benar-benar menghapus fungsionalitas dalam rilis *major* yang baru harus ada setidaknya satu rilis *minor* yang berisi pengusangan itu sehingga pengguna dapat beralih dengan lancar ke API yang baru. + +Tentang +------- + +Spesifikasi Pemversian Semantik dibuat oleh [Tom Preston-Werner](http://tom.preston-werner.com), pembuat Gravatars dan *cofounder* dari GitHub. + +Terjemahan Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com), [Christian B. Wibowo](https://github.com/cwibowo), dan [Hans5958](https://github.com/Hans5958). + +Untuk saran dan kritik, silahkan [buka issue di GitHub](https://github.com/mojombo/semver/issues). + +Lisensi +------- + +[Creative Commons ― CC BY 3.0](http://creativecommons.org/licenses/by/3.0/) diff --git a/lang/id/spec/v2.0.0-rc.2.md b/lang/id/spec/v2.0.0-rc.2.md new file mode 100644 index 00000000..222a5f85 --- /dev/null +++ b/lang/id/spec/v2.0.0-rc.2.md @@ -0,0 +1,109 @@ +--- +title: Pemversian Semantik 2.0.0-rc-2 +language: id +--- + +Pemversian Semantik 2.0.0-rc.2 +============================== + +Pendahuluan +----------- + +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 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 berasumsi versi mana yang bisa digunakan dengan versi yang lain. *Dependency hell* adalah saat Anda berada pada satu atau dua masalah ini, yang menahan Anda untuk bergerak maju dengan aman dan mudah. + +Sebagai solusi permasalahan ini, saya mengusulkan seperangkat aturan dan persayaratan sederhana yang menentukan bagaimana nomor versi diberikan dan bertambah. Agar sistem ini dapat bekerja, Anda harus mengumumkan API publik terlebih dahulu. Ini dapat terdiri dari dokumentasi atau diberlakukan oleh kode itu sendiri. Apapun itu, API ini harus jelas dan tepat. Setelah Anda mengidentifikasi API publik Anda, Anda mengomunikasikan perubahan pada API tersebut dengan penambahan spesifik pada nomor versi Anda. Pertimbangkan format versi X.Y.Z (Major.Minor.Patch). Perbaikan bug yang tidak memengaruhi API tersebut akan menambah versi *patch*, penambahan/perubahan API yang kompatibel dengan versi sebelumnya akan menambah versi *minor*, dan perubahan API yang tidak kompatibel dengan versi sebelumnya akan menambah versi major. + +Standar ini bernama "Pemversian Semantik". Dengan skema ini, setiap orang yang melihat angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut. + +Spesifikasi Pemversian Semantik (SemVer) +---------------------------------------- + +Kata/frasa "HARUS" ("MUST"), "TIDAK BOLEH" ("MUST NOT"), "DIBUTUHKAN" ("REQUIRED"), "SEHARUSNYA" ("SHALL"), "JANGAN SAMPAI" ("SHALL NOT"), "SEBAIKNYA" ("SHOULD"), "SEBAIKNYA TIDAK" ("SHOULD NOT"), "DIREKOMENDASIKAN" ("RECOMMENDED"), "BISA" ("MAY") di dokumen ini sesuai dengan [RFC 2119](http://tools.ietf.org/html/rfc2119). + +1. Perangkat lunak dengan Pemversian Semantik HARUS menentukan API public. Bisa dijelaskan dengan kode, atau ditulis di dokumentasi saja. Apapun itu harus ditulis dengan jelas dan akurat. + +1. Versi normal HARUS ditulis dalam bentuk X.Y.Z, dengan X, Y, dan Z adalah bilangan bulat nonnegatif. X adalah versi *major*, Y adalah *minor*, dan Z adalah *patch*. Setiap elemen HARUS bertambah secara numerik dengan kenaikan sebesar satu. Contohnya: 1.9.0 -> 1.10.0 -> 1.11.0 + +1. Setelah sebuah paket berversi dirilis, isi dari versi tersebut TIDAK BOLEH diubah. Setiap perubahan HARUS dirilis sebagai versi baru. + +1. Versi *major* 0 (0.y.z) adalah untuk pengembangan awal. Apapun bisa bisa berubah kapanpun. API publik sebaiknya dianggap tidak stabil di versi ini. + +1. Versi 1.0.0 adalah titik awal API publik. Cara nomor versi ini dinaikkan setelah rilis ini adalah tergantung dengan API publik ini dan bagaimana ia berubah. + +1. Versi *patch* Z (x.y.Z \| x > 0) HARUS dinaikkan jika ada perbaikan bug yang kompatibel dengan versi lama. Sebuah perbaikan bug didefinisikan sebagai perubahan internal yang memperbaiki perilaku yang salah. + +1. Versi *minor* Y (x.Y.z \| x > 0) HARUS dinaikkan jika ada fitur baru yang kompatibel dengan versi lama dalam API publik. Ini HARUS dinaikkan jika sebuah fungsionalitas API publik dibuat usang. Ini BISA dinaikkan jika ada tambahan fungsionalitas substansial atau terjadi peningkatan di dalam kode privat. Ini BISA diubah bersama dengan perubahan tingkat *patch*. Versi *patch* HARUS dikembalikan ke angka 0 jika versi *minor* dinaikkan. + +1. Versi *major* X (X.y.z \| X > 0) HARUS dinaikkan jika ada perubahan yang membuat versi baru tidak kompatibel dengan versi lama pada API publik. Ini BISA diubah bersama dengan perubahan tingkat *patch* dan *minor*. Versi *minor* dan *patch* HARUS dikembalikan ke angka 0 jika versi *major* dinaikkan. + +1. Versi prarilis BISA ditulis dengan menambahkan tanda hubung dan rangkaian pengenal dengan pemisah titik tepat setelah versi *patch*. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda hubung [0-9A-Za-z]. Versi prarilis diperbolehkan, namun memiliki presendens yang lebih rendah dibandingkan dengan versi normal. Contoh: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92. + +1. *Build metadata* BISA ditulis didahului dengan tanda tambah dan rangkaian pengenal dengan pemisah titik setelah versi *patch* atau prarilis. *Build metadata* HARUS ditulis dengan huruf ASCII alfanumerik dan tanda hubung [0-9A-Za-z]. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda hubung [0-9A-Za-z]. *Build metadata* HARUS diabaikan saat menentukan presedens versi. Dengan begitu, dua versi yang berbada hanya di *build metadata*-nya memiliki versi yang sama. Contoh: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3\-\-\-\-117B344092BD. + +1. Presedens HARUS dihitung dengan memisahkan versi menjadi pengenal *major*, *minor*, *patch*, dan prarilis dalam urutan tersebut (*Build metadata* tidak diperhitungkan dalam pengurutan). Presedens prarilis HARUS ditentukan dengan membandingkan setiap pengenal yang dipisahkan titik sebagai berikut: pengenal yang hanya terdiri dari angka dibandingkan secara numerik dan pengenal dengan huruf atau tanda hubung dibandingkan secara leksikal dalam urutan pengurutan ASCII. Pengenal numerik selalu memiliki prioritas yang lebih rendah daripada pengenal non-numerik. Contoh: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. + +Kenapa Menggunakan Pemversian Semantik? +--------------------------------------- + +Ini bukanlah ide baru yang revolusioner. Faktanya, kalian mungkin sudah menggunakan standar ini, hanya saja tidak terlalu ketat. Masalahnya, "tidak teralu ketat" saja tidak cukup bagus. Tanpa kepatuhan terhadap beberapa jenis spesifikasi formal, nomor versi adalah pada dasarnya tidak berguna untuk manajemen dependensi. Dengan memberikan nama dan definisi yang jelas definisi yang jelas untuk ide-ide tersebut, mengkomunikasikan maksud Anda kepada pengguna perangkat lunak Anda menjadi lebih mudah. Setelah maksud ini jelas, spesifikasi ketergantungan yang fleksibel (tetapi tidak terlalu fleksibel) akhirnya dapat dibuat. + +Contoh sederhana ini menunjukkan manfaat Pemversian 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 Pemversian Semantik, "MobilPemadamKebakaran" bisa dengan yakin menggunakan modul "Tangga" selama modul tersebut mempunyai versi antara 3.1.0 sampai dengan sebelum versi 4.0.0. + +Sebagai pengembang yang bertanggung jawab, tentu saja Anda ingin memverifikasi bahwa peningkatan paket berfungsi seperti yang diiklankan. Dunia nyata tidaklah pasti; tidak ada yang bisa kita lakukan selain waspada. Yang bisa Anda lakukan adalah membiarkan Pemversian Semantik memberi Anda cara yang masuk akal untuk merilis dan memutakhirkan paket tanpa harus menggulirkan versi baru dari paket dependen, membuat Anda menghemat waktu dan kerumitan. + +Jika menurut kalian aturan ini bagus, cara untuk memulai menggunakan pemversian semantik adalah dengan menautkan situs ini dalam README kalian supaya orang lain bisa tahu mengenai aturan ini dan mulai menggunakannya juga. + +Pertanyaan Yang Sering Diajukan +------------------------------- + +### Bagaimana cara menangani revisi dalam fase pengembangan awal 0.y.z? + +Hal yang paling sederhana untuk dilakukan adalah memulai rilis pengembangan awal Anda pada 0.1.0 dan kemudian meningkatkan versi minor untuk setiap rilis berikutnya. + +### Bagaimana saya tahu kapan merilis 1.0.0? + +Jika perangkat lunak Anda digunakan dalam produksi, mungkin perangkat lunak Anda sudah versi 1.0.0. Jika Anda memiliki API yang stabil yang menjadi andalan pengguna, Anda harusnya sudah pada 1.0.0. Jika Anda sangat mengkhawatirkan kompatibilitas versi lama, Anda mungkin sudah pada 1.0.0. + +### Bukankah standar ini mencegah perkembangan yang cepat? + +Versi *major* nol adalah tentang pengembangan yang cepat. Jika Anda mengubah API setiap hari, Anda harus tetap berada di versi 0.y.z atau di pengembangan terpisah yang bekerja pada versi *major* berikutnya. + +### Jika perubahan terkecil yang tidak kompatibel dengan API publik memerlukan kenaikkan versi *major*, bukankah saya akan berakhir di versi 42.0.0 dengan sangat cepat? + +Ini adalah pertanyaan tentang pengembangan yang bertanggung jawab dan pandangan ke depan. Perubahan yang tidak kompatibel tidak boleh diperkenalkan dengan mudah ke perangkat lunak yang memiliki banyak kode dependen. Biaya yang harus dikeluarkan untuk meng-upgrade bisa sangat besar. Kewajiban mengganti versi *major* untuk merilis perubahan yang tidak kompatibel seharusnya membuat Anda memikirkan dampak dari perubahan Anda, dan mengevaluasi perbandingan biaya dan manfaat yang terkait. + +### Mendokumentasikan seluruh API publik sangatlah merepotkan! + +Sudah tanggung jawab Anda sebagai pengembang profesional untuk mendokumentasikan perangkat lunak untuk digunakan oleh orang lain dengan benar. Mengelola kompleksitas perangkat lunak adalah bagian yang sangat penting dalam menjaga proyek tetap efisien, dan itu sulit dilakukan jika tidak ada yang tahu cara menggunakan perangkat lunak Anda, atau metode apa yang aman untuk dihubungi. Dalam jangka panjang, Pemversian Semantik, dan desakan pada API publik yang terdefinisi dengan baik dapat membuat semua orang dan segala sesuatu berjalan dengan lancar. + +### Bagaimana jika secara tidak sengaja membuat perubahan yang menjadikan versi lama tidak bisa dipakai? + +Setelah Anda menyadari bahwa Anda telah melanggar spesifikasi Pemversian Semantik, perbaiki dan rilis versi *minor* baru yang memperbaiki masalah dan mengembalikan kompatibilitas versi lama. Bahkan dalam kondisi ini, memodifikasi rilis yang telah diberi versi adalah dilarang. Jika mau, dokumentasikan versi yang bermasalah dan memberi tahu pengguna Anda tentang masalah tersebut sehingga mereka mengetahui versi yang bermasalah. + +### Apa yang harus saya lakukan jika saya memperbarui dependensi saya sendiri tanpa mengubah API publik? + +Hal tersebut dianggap kompatibel karena tidak mempengaruhi API publik. Perangkat lunak yang secara eksplisit bergantung pada dependensi yang sama dengan paket Anda harus memiliki spesifikasi dependensi mereka sendiri dan pembuatnya akan memberi tahu konflik yang ada. Menentukan apakah perubahan tersebut merupakan tingkat *patch* atau tingkat *minor* tergantung pada apakah Anda memperbarui dependensi untuk memperbaiki *bug* atau memperkenalkan fungsionalitas baru. Saya biasanya mengharapkan kode tambahan untuk contoh yang kedua, yang dalam hal ini jelas merupakan kenaikan tingkat *minor*. + +### Apa yang harus saya lakukan jika bug yang sedang diperbaiki mengembalikan kode agar sesuai dengan API publik (misalnya, kode tidak sinkron dengan dokumentasi API publik)? + +Gunakan kebijakan terbaik Anda. Jika Anda memiliki audiens yang sangat besar yang akan terpengaruh secara drastis dengan apa yang dimaksudkan oleh API publik, maka lebih baik melakukan rilis versi *major*, meskipun perbaikannya dapat sangat dianggap sebagai rilis *patch*. Ingat, Pemversian Semantik adalah segalanya tentang menyampaikan makna melalui perubahan nomor versi. Jika perubahan ini perubahan ini penting bagi pengguna Anda, gunakan nomor versi itu untuk memberi tahu mereka. + +### Bagaimana cara menangani fungsionalitas yang sudah diusangkan? + +Mengusangkan fungsionalitas yang ada adalah hal yang lumrah dalam pengembangan perangkat lunak dan sering kali diperlukan untuk membuat suatu kemajuan. Ketika Anda mengusangkan bagian dari API publik Anda, Anda harus melakukan dua hal: (1) memperbarui dokumentasi Anda untuk memberi tahu pengguna tahu tentang perubahan tersebut, dan (2) mengeluarkan rilis minor baru dengan penghentian yang baru dengan pengusangan itu dibuat. Sebelum Anda benar-benar menghapus fungsionalitas dalam rilis *major* yang baru harus ada setidaknya satu rilis *minor* yang berisi pengusangan itu sehingga pengguna dapat beralih dengan lancar ke API yang baru. + +Tentang +------- + +Spesifikasi Pemversian Semantik dibuat oleh [Tom Preston-Werner](http://tom.preston-werner.com), pembuat Gravatars dan *cofounder* dari GitHub. + +Terjemahan Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com), [Christian B. Wibowo](https://github.com/cwibowo), dan [Hans5958](https://github.com/Hans5958). + +Untuk saran dan kritik, silahkan [buka issue di GitHub](https://github.com/mojombo/semver/issues). + +Lisensi +------- + +[Creative Commons ― CC BY 3.0](http://creativecommons.org/licenses/by/3.0/) diff --git a/lang/id/spec/v2.0.0.md b/lang/id/spec/v2.0.0.md index de9be344..84b3d3ee 100644 --- a/lang/id/spec/v2.0.0.md +++ b/lang/id/spec/v2.0.0.md @@ -1,15 +1,13 @@ --- -title: Versi Semantik 2.0.0 +title: Pemversian Semantik 2.0.0 language: id -redirect_from: /lang/id/ -author: Aditya Purwa --- -Versi Semantik 2.0.0 -============================== +Pemversian Semantik 2.0.0 +========================= Ringkasan -------- +--------- Versi semantik ditulis dalam bentuk MAJOR.MINOR.PATCH, dengan: @@ -21,144 +19,211 @@ Tambahan label dan versi sebelum rilis atau info tambahan tersedia sebagai ekste MAJOR.MINOR.PATCH. Pendahuluan ------------- - -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". +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. -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. +Dalam sistem yang saling terkait, merilis versi baru 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 berasumsi versi mana yang bisa digunakan dengan versi yang lain. *Dependency hell* adalah saat Anda berada pada satu atau dua masalah ini, yang menahan Anda untuk bergerak maju dengan aman dan mudah. -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. +Sebagai solusi permasalahan ini, kami mengusulkan seperangkat aturan dan persayaratan sederhana yang menentukan bagaimana nomor versi diberikan dan bertambah. Aturan-aturan ini didasarkan pada, namun tidak terbatas pada, praktik-praktik yang sudah ada pada perangkat lunak sumber terbuka dan tertutup. Agar sistem ini dapat bekerja, Anda harus mengumumkan API publik terlebih dahulu. Ini dapat terdiri dari dokumentasi atau diberlakukan oleh kode itu sendiri. Apapun itu, API ini harus jelas dan tepat. Setelah Anda mengidentifikasi API publik Anda, Anda mengomunikasikan perubahan pada API tersebut dengan penambahan spesifik pada nomor versi Anda. Pertimbangkan format versi X.Y.Z (Major.Minor.Patch). Perbaikan bug yang tidak memengaruhi API tersebut akan menambah versi *patch*, penambahan/perubahan API yang kompatibel dengan versi sebelumnya akan menambah versi *minor*, dan perubahan API yang tidak kompatibel dengan versi sebelumnya akan menambah versi 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. +Standar ini bernama "Pemversian Semantik". Dengan skema ini, setiap orang yang melihat angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut. -Spesifikasi Versi Semantik (VerSem) ------------------------------------------- +Spesifikasi Pemversian Semantik (SemVer) +---------------------------------------- -Kata HARUS, TIDAK BOLEH, DIBUTUHKAN, SEHARUSNYA, JANGAN SAMPAI, SEBAIKNYA, SEBAIKNYA TIDAK, -DIREKOMENDASIKAN, BISA, dan OPSIONAL di dokumen ini sesuai dengan [RFC 2119](http://tools.ietf.org/html/rfc2119). +Kata/frasa "HARUS" ("MUST"), "TIDAK BOLEH" ("MUST NOT"), "DIBUTUHKAN" ("REQUIRED"), "SEHARUSNYA" ("SHALL"), "JANGAN SAMPAI" ("SHALL NOT"), "SEBAIKNYA" ("SHOULD"), "SEBAIKNYA TIDAK" ("SHOULD NOT"), "DIREKOMENDASIKAN" ("RECOMMENDED"), "BISA" ("MAY") di dokumen ini sesuai dengan [RFC 2119](https://tools.ietf.org/html/rfc2119). -1. Perangkat lunak dengan Versi Semantik harus menentukan API public. Bisa -dijelaskan dengan kode, atau ditulis di dokumentasi, ditulis dengan jelas dan akurat. +1. Perangkat lunak dengan Pemversian Semantik HARUS menentukan API public. Bisa dijelaskan dengan kode, atau ditulis di dokumentasi saja. Apapun itu HARUS ditulis dengan jelas dan akurat. -2. 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. +1. Versi normal HARUS ditulis dalam bentuk X.Y.Z, dengan X, Y, dan Z adalah bilangan bulat nonnegatif, dan TIDAK BOLEH didahului angka 0 (contoh 01.02.03). X adalah versi *major*, Y adalah *minor*, dan Z adalah *patch*. Setiap elemen HARUS bertambah secara numerik dengan kenaikan sebesar satu. Contohnya: 1.9.0 -> 1.10.0 -> 1.11.0 -3. Setelah versi dirilis, isi dari versi tersebut TIDAK BOLEH dirubah. Setiap perubahan HARUS -merilis versi baru. +1. Setelah sebuah paket berversi dirilis, isi dari versi tersebut TIDAK BOLEH diubah. Setiap perubahan HARUS dirilis sebagai versi baru. -4. Versi major 0 (0.y.z) adalah untuk pengembangan awal, saat banyak perubahan bisa terjadi. API publik +1. Versi *major* 0 (0.y.z) adalah untuk pengembangan awal. Apapun BISA bisa berubah kapan saja. API publik SEBAIKNYA dianggap tidak stabil di versi ini. -5. Versi 1.0.0 adalah titik awal API publik, setiap versi baru ditulis berdasarkan versi ini. +1. Versi 1.0.0 adalah titik awal API publik. Cara nomor versi ini dinaikkan setelah rilis ini adalah tergantung dengan API publik ini dan bagaimana ia berubah. + +1. Versi *patch* Z (x.y.Z \| x > 0) HARUS dinaikkan jika ada perbaikan bug yang kompatibel dengan versi lama. Sebuah perbaikan bug didefinisikan sebagai perubahan internal yang memperbaiki perilaku yang salah. + +1. Versi *minor* Y (x.Y.z \| x > 0) HARUS dinaikkan jika ada fitur baru yang kompatibel dengan versi lama dalam API publik. Ini HARUS dinaikkan jika sebuah fungsionalitas API publik dibuat usang. Ini BISA dinaikkan jika ada tambahan fungsionalitas substansial atau terjadi peningkatan di dalam kode privat. Ini BISA diubah bersama dengan perubahan tingkat *patch*. Versi *patch* HARUS dikembalikan ke angka 0 jika versi *minor* dinaikkan. + +1. Versi *major* X (X.y.z \| X > 0) HARUS dinaikkan jika ada perubahan yang membuat versi baru tidak kompatibel dengan versi lama pada API publik. Ini juga BISA diubah bersama dengan perubahan tingkat *patch* dan *minor*. Versi *minor* dan *patch* HARUS dikembalikan ke angka 0 jika versi *major* dinaikkan. + +1. Versi prarilis BISA ditulis dengan menambahkan tanda hubung dan rangkaian pengenal dengan pemisah titik tepat setelah versi *patch*. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda hubung [0-9A-Za-z]. Pengenal TIDAK BOLEH kosong. Pengenal numerik TIDAK BOLEH didahului angka 0. Versi prarilis memiliki presendens yang lebih rendah dibandingkan dengan versi normal yang terkait. Versi prarilis dianggap tidak stabil dan mungkin tidak memuaskan persyaratan kompatibilitas yang dimaksudkan seperti yang ditunjukkan oleh versi normal yang terkait. Contoh: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.\-\-. + +1. *Build metadata* BISA ditulis didahului dengan tanda tambah dan rangkaian pengenal dengan pemisah titik setelah versi *patch* atau prarilis. *Build metadata* HARUS ditulis dengan huruf ASCII alfanumerik dan tanda hubung [0-9A-Za-z]. Pengenal ini HARUS terdiri dari hanya alfanumerik ASCII dan tanda hubung [0-9A-Za-z]. Pengenal TIDAK BOLEH kosong. *Build metadata* HARUS diabaikan saat menentukan presedens versi. Dengan begitu, dua versi yang berbada hanya di *build metadata*-nya memiliki preseden yang sama. Contoh: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3\-\-\-\-117B344092BD. + +1. Presedens mengacu pada bagaimana versi-versi dibandingkan satu sama lain ketika diurutkan. + + 1. Presedens HARUS dihitung dengan memisahkan versi menjadi pengenal *major*, *minor*, *patch*, dan prarilis dalam urutan tersebut (*Build metadata* tidak diperhitungkan dalam pengurutan). + + 1. Presedens ditentukan oleh perbedaan pertama saat membandingkan masing-masing pengenal ini dari kiri ke kanan sebagai berikut: *Major*, *minor*, dan *patch* selalu dibandingkan secara numerik. + + Contoh: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. + + 1. Saat versi *major*, *minor*, dan *patch* sama, versi prarilis lebih rendah memiliki presedens lebih rendah dibandingkan dengan versi normal: + + Contoh: 1.0.0-alpha < 1.0.0. + + 1. Prioritas untuk dua versi prarilis dengan versi *major*, *minor*, dan *patch* HARUS ditentukan dengan membandingkan setiap pengenal yang dipisahkan titik dari kiri ke kanan hingga ditemukan perbedaan sebagai berikut: + + 1. Pengenal yang hanya terdiri dari angka dibandingkan secara numerik. + + 1. Pengenal dengan huruf atau tanda hubung dibandingkan secara leksikal dalam urutan pengurutan ASCII. + + 1. Pengenal numerik selalu memiliki presedens yang lebih rendah daripada pengenal non-numerik pengenal non-numerik. + + 1. Suatu set yang lebih besar dari bidang prarilis memiliki presedens yang lebih tinggi daripada yang set yang lebih kecil, jika semua pengenal sebelumnya sama. + + Contoh: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. + +Grammar Bentuk Backus–Naur untuk Versi SemVer Valid +--------------------------------------------------- +``` + ::= + | "-" + | "+" + | "-" "+" + + ::= "." "." -6. Versi patch Z (x.y.Z | x > 0) HARUS dinaikkan jika ada perbaikan bug tanpa menambah fitur. + ::= -7. 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. + ::= -8. 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. + ::= -9. 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. + ::= -10. _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 + ::= + | "." -11. Penentuan versi mana yang didahulukan diurutkan berdasarkan versi stabil, lalu versi sebelum rilis, dan versi dengan _Build Metadata_. Jika ada versi stabil yang sama, maka diambil versi dengan angka paling tinggi. Contoh 2.0.0 lebih didahulukan dari 1.0.0. Jika ada versi sebelum rilis, maka diambil versi yang stabil terlebih dahulu. Contoh, 2.0.0 lebih didahulukan dari 2.0.0-alpha. + ::= -Kenapa Menggunakan Pemberian Versi Semantik ----------------------------- + ::= + | "." -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. + ::= "0" + | + | + + ::= + | + + ::= + | + + ::= + | "-" + + ::= + | + + ::= "0" + | + + ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" + + ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" + | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" + | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" + | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" + | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" + | "y" | "z" +``` + +Kenapa Menggunakan Pemversian Semantik? +--------------------------------------- + +Ini bukanlah ide baru yang revolusioner. Faktanya, kalian mungkin sudah menggunakan standar ini, hanya saja tidak terlalu ketat. Masalahnya, "tidak teralu ketat" saja tidak cukup bagus. Tanpa kepatuhan terhadap beberapa jenis spesifikasi formal, nomor versi adalah pada dasarnya tidak berguna untuk manajemen dependensi. Dengan memberikan nama dan definisi yang jelas definisi yang jelas untuk ide-ide tersebut, mengkomunikasikan maksud Anda kepada pengguna perangkat lunak Anda menjadi lebih mudah. Setelah maksud ini jelas, spesifikasi ketergantungan yang fleksibel (tetapi tidak terlalu fleksibel) akhirnya dapat dibuat. + +Contoh sederhana ini menunjukkan manfaat Pemversian 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 Pemversian Semantik, "MobilPemadamKebakaran" bisa dengan yakin menggunakan modul "Tangga" selama modul tersebut mempunyai versi antara 3.1.0 sampai dengan sebelum versi 4.0.0. + +Sebagai pengembang yang bertanggung jawab, tentu saja Anda ingin memverifikasi bahwa peningkatan paket berfungsi seperti yang diiklankan. Dunia nyata tidaklah pasti; tidak ada yang bisa kita lakukan selain waspada. Yang bisa Anda lakukan adalah membiarkan Pemversian Semantik memberi Anda cara yang masuk akal untuk merilis dan memutakhirkan paket tanpa harus menggulirkan versi baru dari paket dependen, membuat Anda menghemat waktu dan kerumitan. + +Jika menurut kalian aturan ini bagus, cara untuk memulai menggunakan pemversian semantik adalah dengan menautkan situs ini dalam README kalian supaya orang lain bisa tahu mengenai aturan ini dan mulai menggunakannya juga. Pertanyaan Yang Sering Diajukan ---- +------------------------------- -### Bagaimana memulai versi pengembangan 0.y.z? +### Bagaimana cara menangani revisi dalam fase pengembangan awal 0.y.z? -Paling mudah adalah memulai dengan versi 0.1.0. +Hal yang paling sederhana untuk dilakukan adalah memulai rilis pengembangan awal Anda pada 0.1.0 dan kemudian meningkatkan versi minor untuk setiap rilis berikutnya. -### Kapan harus dirilis versi 1.0.0? +### Bagaimana saya tahu kapan merilis 1.0.0? -Ketika sistem yang dikembangkan sudah stabil dan digunakan dalam lingkungan produksi, kalian bisa -mulai menentukannya dengan versi 1.0.0. +Jika perangkat lunak Anda digunakan dalam produksi, mungkin perangkat lunak Anda sudah versi 1.0.0. Jika Anda memiliki API yang stabil yang menjadi andalan pengguna, Anda harusnya sudah pada 1.0.0. Jika Anda sangat mengkhawatirkan kompatibilitas versi lama, Anda mungkin sudah pada 1.0.0. ### Bukankah standar ini mencegah perkembangan yang cepat? -Versi 0.1.0 adalah tempat dimana banyak perubahan terjadi, jadi standar ini tidak mencegah perkembangan yang cepat. +Versi *major* nol adalah tentang pengembangan yang cepat. Jika Anda mengubah API setiap hari, Anda harus tetap berada di versi 0.y.z atau di pengembangan terpisah yang bekerja pada versi *major* berikutnya. -### Jika perubahan yang tidak membuat versi lama tidak bisa dipakai sangat banyak, bukankah berarti nanti dengan cepat versi kita membengkan menjadi seperti versi 100.0.0? +### Jika perubahan terkecil yang tidak kompatibel dengan API publik memerlukan kenaikkan versi *major*, bukankah saya akan berakhir di versi 42.0.0 dengan sangat cepat? -Ini lebih ke permasalahan pengembangan, jika pengembangan dilakukan dengan seksama, maka seharusnya tidak terjadi perubahan yang terlalu signifikan dalam waktu yang cepat. +Ini adalah pertanyaan tentang pengembangan yang bertanggung jawab dan pandangan ke depan. Perubahan yang tidak kompatibel tidak boleh diperkenalkan dengan mudah ke perangkat lunak yang memiliki banyak kode dependen. Biaya yang harus dikeluarkan untuk meng-upgrade bisa sangat besar. Kewajiban mengganti versi *major* untuk merilis perubahan yang tidak kompatibel seharusnya membuat Anda memikirkan dampak dari perubahan Anda, dan mengevaluasi perbandingan biaya dan manfaat yang terkait. -### Terlalu merepotkan! +### Mendokumentasikan seluruh API publik sangatlah merepotkan! -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. +Sudah tanggung jawab Anda sebagai pengembang profesional untuk mendokumentasikan perangkat lunak untuk digunakan oleh orang lain dengan benar. Mengelola kompleksitas perangkat lunak adalah bagian yang sangat penting dalam menjaga proyek tetap efisien, dan itu sulit dilakukan jika tidak ada yang tahu cara menggunakan perangkat lunak Anda, atau metode apa yang aman untuk dihubungi. Dalam jangka panjang, Pemversian Semantik, dan desakan pada API publik yang terdefinisi dengan baik dapat membuat semua orang dan segala sesuatu berjalan dengan lancar. ### Bagaimana jika secara tidak sengaja membuat perubahan yang menjadikan versi lama tidak bisa dipakai? -Langsung ganti perubahan tersebut dan kembalikan supaya masih bisa digunakan versi lama dan naikkan versi minor. +Setelah Anda menyadari bahwa Anda telah melanggar spesifikasi Pemversian Semantik, perbaiki dan rilis versi *minor* baru yang memperbaiki masalah dan mengembalikan kompatibilitas versi lama. Bahkan dalam kondisi ini, memodifikasi rilis yang telah diberi versi adalah dilarang. Jika mau, dokumentasikan versi yang bermasalah dan memberi tahu pengguna Anda tentang masalah tersebut sehingga mereka mengetahui versi yang bermasalah. -### Bagaimana jika saya merubah kebutuhan sistem tanpa merubah API publik? +### Apa yang harus saya lakukan jika saya memperbarui dependensi saya sendiri tanpa mengubah API publik? -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. +Hal tersebut dianggap kompatibel karena tidak mempengaruhi API publik. Perangkat lunak yang secara eksplisit bergantung pada dependensi yang sama dengan paket Anda harus memiliki spesifikasi dependensi mereka sendiri dan pembuatnya akan memberi tahu konflik yang ada. Menentukan apakah perubahan tersebut merupakan tingkat *patch* atau tingkat *minor* tergantung pada apakah Anda memperbarui dependensi untuk memperbaiki *bug* atau memperkenalkan fungsionalitas baru. Kami biasanya mengharapkan kode tambahan untuk contoh yang kedua, yang dalam hal ini jelas merupakan kenaikan tingkat *minor*. -### Bagaimana jika perubahan yang terjadi ternyata sangat besar dan sudah dirilis di versi patch? +### Bagaimana jika saya secara tidak sengaja mengubah API publik dengan cara yang tidak sesuai dengan perubahan nomor versi (misalnya, kode secara tidak benar memperkenalkan perubahan besar dalam rilis *patch*)? -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. +Gunakan kebijakan terbaik Anda. Jika Anda memiliki audiens yang sangat besar yang akan terpengaruh secara drastis dengan apa yang dimaksudkan oleh API publik, maka lebih baik melakukan rilis versi *major*, meskipun perbaikannya dapat sangat dianggap sebagai rilis *patch*. Ingat, Pemversian Semantik adalah segalanya tentang menyampaikan makna melalui perubahan nomor versi. Jika perubahan ini perubahan ini penting bagi pengguna Anda, gunakan nomor versi itu untuk memberi tahu mereka. -### Bagaimana jika ada fitur yang usang? +### Bagaimana cara menangani fungsionalitas yang sudah diusangkan? -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. +Mengusangkan fungsionalitas yang ada adalah hal yang lumrah dalam pengembangan perangkat lunak dan sering kali diperlukan untuk membuat suatu kemajuan. Ketika Anda mengusangkan bagian dari API publik Anda, Anda harus melakukan dua hal: (1) memperbarui dokumentasi Anda untuk memberi tahu pengguna tahu tentang perubahan tersebut, dan (2) mengeluarkan rilis minor baru dengan penghentian yang baru dengan pengusangan itu dibuat. Sebelum Anda benar-benar menghapus fungsionalitas dalam rilis *major* yang baru harus ada setidaknya satu rilis *minor* yang berisi pengusangan itu sehingga pengguna dapat beralih dengan lancar ke API yang baru. ### Apakah Versi Semantik punya batasan jumlah karakter dalam versi? -Tidak ada, tapi sebaiknya gunakan saja secukupnya. Versi sepanjang 255 terlalu banyak dan membuat pengguna kesulitan untuk membacanya. +Tidak, tetapi gunakan kebijakan yang baik. Misalnya, versi dengan panjang 255 karakter mungkin teralu banyak. Selain itu, sistem tertentu mungkin memiliki batasan mereka sendiri pada ukuran string. + +### Apakah ada *regular expression* (RegEx) yang disarankan untuk memeriksa string SemVer? + +Ada dua. Satu dengan grup bernama untuk sistem yang didukung (PCRE [Perl Compatible Regular Expressions, yaitu Perl, PHP dan R], Python dan Go). + +Lihat: + +``` +^(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` + +Dan satu lagi dengan kelompok tangkapan bernomor (jadi cg1 = *major*, cg2 = *minor*, cg3 = *patch*, cg4 = prarilis dan cg5 = *build metadata*) yang kompatibel dengan ECMA Script (JavaScript), PCRE (Perl Compatible Regular Expressions, +yaitu Perl, PHP dan R), Python dan Go. + +``` +^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` Tentang ------ +------- -Spesifikasi Versi Semantik dibuat oleh [Tom Preston-Werner](http://tom.preston-werner.com), pembuat Gravatars dan -cofounder dari GitHub. +Spesifikasi Pemversian Semantik awalnya dibuat oleh [Tom Preston-Werner](http://tom.preston-werner.com), pembuat Gravatar dan *cofounder* dari GitHub. -Translasi Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com) dan dikoreksi oleh -[Christian B. Wibowo](https://github.com/cwibowo). +Terjemahan Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com), [Christian B. Wibowo](https://github.com/cwibowo), dan [Hans5958](https://github.com/Hans5958). -Untuk saran dan kritik, [buka issue di GitHub](https://github.com/mojombo/semver/issues). +Untuk saran dan kritik, silahkan [buka issue di GitHub](https://github.com/semver/semver/issues). Lisensi ------- diff --git a/lang/it/index.md b/lang/it/index.md index e422ee47..09313c71 100644 --- a/lang/it/index.md +++ b/lang/it/index.md @@ -285,7 +285,7 @@ Traduzione a cura del [Java User Group Padova](http://www.jugpadova.it/): - [Anicet Foba Togue](https://twitter.com/atogue) (revisore) Per lasciare il vostro feedback per favore [aprite una segnalazione su -GitHub](https://github.com/mojombo/semver/issues). +GitHub](https://github.com/semver/semver/issues). Licenza ------- diff --git a/lang/it/spec/v2.0.0.md b/lang/it/spec/v2.0.0.md index 86dbd634..9c670a59 100644 --- a/lang/it/spec/v2.0.0.md +++ b/lang/it/spec/v2.0.0.md @@ -285,7 +285,7 @@ Traduzione a cura del [Java User Group Padova](http://www.jugpadova.it/): - [Anicet Foba Togue](https://twitter.com/atogue) (revisore) Se vi piacerebbe lasciare un commento, per favore [aprite una segnalazione su -GitHub](https://github.com/mojombo/semver/issues). +GitHub](https://github.com/semver/semver/issues). Licenza ------- diff --git a/lang/ka/index.md b/lang/ka/index.md index 91b9d3f3..02659488 100644 --- a/lang/ka/index.md +++ b/lang/ka/index.md @@ -253,7 +253,7 @@ Firetruck იყენებს ფუნქციონალს, რომე და GitHub-ის თანადამფუძნებელი. თუ გსურთ დატოვოთ თქვენი გამოხმაურება, გთხოვთ შექმნათ -[დაამატოთ თემა GitHub-ზე](https://github.com/mojombo/semver/issues). +[დაამატოთ თემა GitHub-ზე](https://github.com/semver/semver/issues). ### ქართული თარგმანი diff --git a/lang/ka/spec/v2.0.0.md b/lang/ka/spec/v2.0.0.md index 91b9d3f3..02659488 100644 --- a/lang/ka/spec/v2.0.0.md +++ b/lang/ka/spec/v2.0.0.md @@ -253,7 +253,7 @@ Firetruck იყენებს ფუნქციონალს, რომე და GitHub-ის თანადამფუძნებელი. თუ გსურთ დატოვოთ თქვენი გამოხმაურება, გთხოვთ შექმნათ -[დაამატოთ თემა GitHub-ზე](https://github.com/mojombo/semver/issues). +[დაამატოთ თემა GitHub-ზე](https://github.com/semver/semver/issues). ### ქართული თარგმანი diff --git a/lang/ko/index.md b/lang/ko/index.md index 03d8e98f..e87b79b6 100644 --- a/lang/ko/index.md +++ b/lang/ko/index.md @@ -203,7 +203,7 @@ See: 유의적 버전 명세는 그라바타(Gravatars)의 창시자이자 깃헙(GitHub)의 공동창업자인 [톰 프레스턴-베르너(Tom Preston-Werner)](http://tom.preston-werner.com)가 작성했다. -원문에 대한 의견을 남기고자 한다면, [원문 깃헙에 이슈를 작성](https://github.com/mojombo/semver/issues)해 주기 바란다. +원문에 대한 의견을 남기고자 한다면, [원문 깃헙에 이슈를 작성](https://github.com/semver/semver/issues)해 주기 바란다. 한국어 번역은 [김대현](http://hatemogi.com)이 했고, 관련한 의견은 [한국어판 깃헙에 이슈로 남겨주기](https://github.com/hatemogi/semver/issues) 바란다. diff --git a/lang/ko/spec/v2.0.0.md b/lang/ko/spec/v2.0.0.md index 03d8e98f..e87b79b6 100644 --- a/lang/ko/spec/v2.0.0.md +++ b/lang/ko/spec/v2.0.0.md @@ -203,7 +203,7 @@ See: 유의적 버전 명세는 그라바타(Gravatars)의 창시자이자 깃헙(GitHub)의 공동창업자인 [톰 프레스턴-베르너(Tom Preston-Werner)](http://tom.preston-werner.com)가 작성했다. -원문에 대한 의견을 남기고자 한다면, [원문 깃헙에 이슈를 작성](https://github.com/mojombo/semver/issues)해 주기 바란다. +원문에 대한 의견을 남기고자 한다면, [원문 깃헙에 이슈를 작성](https://github.com/semver/semver/issues)해 주기 바란다. 한국어 번역은 [김대현](http://hatemogi.com)이 했고, 관련한 의견은 [한국어판 깃헙에 이슈로 남겨주기](https://github.com/hatemogi/semver/issues) 바란다. diff --git a/lang/pl/index.md b/lang/pl/index.md index 8121e111..60fc84b6 100644 --- a/lang/pl/index.md +++ b/lang/pl/index.md @@ -362,7 +362,7 @@ Autorem specyfikacji wersjonowania semantycznego jest i współzałożyciel GitHuba. Jeśli chcesz podzielić się opinią, prosimy -o [otworzenie zgłoszenia na GitHubie](https://github.com/mojombo/semver/issues). +o [otworzenie zgłoszenia na GitHubie](https://github.com/semver/semver/issues). Licencja -------- diff --git a/lang/pl/spec/v2.0.0.md b/lang/pl/spec/v2.0.0.md index 75422d07..777817d8 100644 --- a/lang/pl/spec/v2.0.0.md +++ b/lang/pl/spec/v2.0.0.md @@ -362,7 +362,7 @@ Autorem specyfikacji wersjonowania semantycznego jest i współzałożyciel GitHuba. Jeśli chcesz podzielić się opinią, prosimy -o [otworzenie zgłoszenia na GitHubie](https://github.com/mojombo/semver/issues). +o [otworzenie zgłoszenia na GitHubie](https://github.com/semver/semver/issues). Licencja -------- diff --git a/lang/pt-BR/spec/v2.0.0.md b/lang/pt-BR/spec/v2.0.0.md index b3ebdbbb..54bab3a8 100644 --- a/lang/pt-BR/spec/v2.0.0.md +++ b/lang/pt-BR/spec/v2.0.0.md @@ -288,7 +288,7 @@ participação de: Toda colaboração na tradução pode ser acompanhada no link: http://pad.okfn.org/p/Fh9hjBPVu9 -Caso queira deixar sua opinião, por favor [abra uma issue no GitHub](https://github.com/mojombo/semver/issues). +Caso queira deixar sua opinião, por favor [abra uma issue no GitHub](https://github.com/semver/semver/issues). Licença ------- diff --git a/lang/ru/index.md b/lang/ru/index.md index c86730ea..05053880 100644 --- a/lang/ru/index.md +++ b/lang/ru/index.md @@ -256,7 +256,7 @@ FAQ соучредителю GitHub. Если вы хотите оставить отзыв, пожалуйста, [создайте запрос на -GitHub](https://github.com/mojombo/semver/issues). +GitHub](https://github.com/semver/semver/issues). Лицензия -------- diff --git a/lang/ru/spec/v2.0.0.md b/lang/ru/spec/v2.0.0.md index d4194ac3..09538ec5 100644 --- a/lang/ru/spec/v2.0.0.md +++ b/lang/ru/spec/v2.0.0.md @@ -256,7 +256,7 @@ FAQ соучредителю GitHub. Если вы хотите оставить отзыв, пожалуйста, [создайте запрос на -GitHub](https://github.com/mojombo/semver/issues). +GitHub](https://github.com/semver/semver/issues). Лицензия -------- diff --git a/lang/sk/index.md b/lang/sk/index.md index 938e8156..e2c012cc 100644 --- a/lang/sk/index.md +++ b/lang/sk/index.md @@ -251,7 +251,7 @@ Autorom špecifikácie sémantického verziovania je spoluzakladateľ projektu Github. Ak chcete zanechať spätnú väzbu, prosím -[cez GitHub](https://github.com/mojombo/semver/issues). +[cez GitHub](https://github.com/semver/semver/issues). ### Preklad diff --git a/lang/sk/spec/v2.0.0.md b/lang/sk/spec/v2.0.0.md index 87ef8409..78863c6e 100644 --- a/lang/sk/spec/v2.0.0.md +++ b/lang/sk/spec/v2.0.0.md @@ -251,7 +251,7 @@ Autorom špecifikácie sémantického verzovania je spoluzakladateľ projektu Github. Ak chcete zanechať spätnú väzbu, prosím -[cez GitHub](https://github.com/mojombo/semver/issues). +[cez GitHub](https://github.com/semver/semver/issues). ### Preklad diff --git a/lang/sl/index.md b/lang/sl/index.md index 5acfbad6..96c09a54 100644 --- a/lang/sl/index.md +++ b/lang/sl/index.md @@ -260,7 +260,7 @@ Slovenski prevod so prispevali: - [Aleš Šarkanj](https://github.com/alsar) Če želite pustiti povratne informacije, prosimo, da [odprete vprašanje na -GitHub-u](https://github.com/mojombo/semver/issues). +GitHub-u](https://github.com/semver/semver/issues). Licenca ------- diff --git a/lang/sl/spec/v2.0.0.md b/lang/sl/spec/v2.0.0.md index 5acfbad6..96c09a54 100644 --- a/lang/sl/spec/v2.0.0.md +++ b/lang/sl/spec/v2.0.0.md @@ -260,7 +260,7 @@ Slovenski prevod so prispevali: - [Aleš Šarkanj](https://github.com/alsar) Če želite pustiti povratne informacije, prosimo, da [odprete vprašanje na -GitHub-u](https://github.com/mojombo/semver/issues). +GitHub-u](https://github.com/semver/semver/issues). Licenca ------- diff --git a/lang/sv/index.md b/lang/sv/index.md index 8659d6e6..7e49dbcf 100644 --- a/lang/sv/index.md +++ b/lang/sv/index.md @@ -237,7 +237,7 @@ Specifikationen för Semantisk versionshantering är skriven av [Tom Preston-Werner](http://tom.preston-werner.com), skapare av Gravatars och medgrundare av GitHub. -Om du vill lämna feedback, [öppna en fråga på GitHub](https://github.com/mojombo/semver/issues). +Om du vill lämna feedback, [öppna en fråga på GitHub](https://github.com/semver/semver/issues). Licens ------- diff --git a/lang/sv/spec/v2.0.0.md b/lang/sv/spec/v2.0.0.md index b0957123..dc1171e6 100644 --- a/lang/sv/spec/v2.0.0.md +++ b/lang/sv/spec/v2.0.0.md @@ -237,7 +237,7 @@ Specifikationen för Semantisk versionshantering är skriven av [Tom Preston-Werner](http://tom.preston-werner.com), skapare av Gravatars och medgrundare av GitHub. -Om du vill lämna feedback, [öppna en fråga på GitHub](https://github.com/mojombo/semver/issues). +Om du vill lämna feedback, [öppna en fråga på GitHub](https://github.com/semver/semver/issues). Licens ------- diff --git a/lang/tr/index.md b/lang/tr/index.md index 503a4973..aab3b376 100644 --- a/lang/tr/index.md +++ b/lang/tr/index.md @@ -121,7 +121,7 @@ Hakkında Anlamsal Sürümlendirme şartnamesi, Gravatar'ların kaşifi ve GitHub'un kurucu ortaklarından olan [Tom Preston-Werner](http://tom.preston-werner.com) tarafından yazılmıştır. -Yorum bırakmak isterseniz, lütfen [GitHub'da bir konu açın](https://github.com/mojombo/semver/issues). +Yorum bırakmak isterseniz, lütfen [GitHub'da bir konu açın](https://github.com/semver/semver/issues). Lisans ------ diff --git a/lang/tr/spec/v2.0.0.md b/lang/tr/spec/v2.0.0.md index 503a4973..aab3b376 100644 --- a/lang/tr/spec/v2.0.0.md +++ b/lang/tr/spec/v2.0.0.md @@ -121,7 +121,7 @@ Hakkında Anlamsal Sürümlendirme şartnamesi, Gravatar'ların kaşifi ve GitHub'un kurucu ortaklarından olan [Tom Preston-Werner](http://tom.preston-werner.com) tarafından yazılmıştır. -Yorum bırakmak isterseniz, lütfen [GitHub'da bir konu açın](https://github.com/mojombo/semver/issues). +Yorum bırakmak isterseniz, lütfen [GitHub'da bir konu açın](https://github.com/semver/semver/issues). Lisans ------ diff --git a/lang/uk/index.md b/lang/uk/index.md index a080e650..b84f31ef 100644 --- a/lang/uk/index.md +++ b/lang/uk/index.md @@ -205,7 +205,7 @@ cg3 = патч, cg4 = передрелізна та cg5 = метадані зб Автором Специфікації Семантичного Версіонування є [Том Престон-Вернер](http://tom.preston-werner.com), засновник Gravatars та співзасновник GitHub. -Якщо ви бажаєте залишити відгук, [відкрийте issue на GitHub](https://github.com/mojombo/semver/issues). +Якщо ви бажаєте залишити відгук, [відкрийте issue на GitHub](https://github.com/semver/semver/issues). Ліцензія -------- diff --git a/lang/uk/spec/v2.0.0.md b/lang/uk/spec/v2.0.0.md index a080e650..b84f31ef 100644 --- a/lang/uk/spec/v2.0.0.md +++ b/lang/uk/spec/v2.0.0.md @@ -205,7 +205,7 @@ cg3 = патч, cg4 = передрелізна та cg5 = метадані зб Автором Специфікації Семантичного Версіонування є [Том Престон-Вернер](http://tom.preston-werner.com), засновник Gravatars та співзасновник GitHub. -Якщо ви бажаєте залишити відгук, [відкрийте issue на GitHub](https://github.com/mojombo/semver/issues). +Якщо ви бажаєте залишити відгук, [відкрийте issue на GitHub](https://github.com/semver/semver/issues). Ліцензія -------- diff --git a/lang/zh-CN/index.md b/lang/zh-CN/index.md index 5cf025aa..2026fbad 100644 --- a/lang/zh-CN/index.md +++ b/lang/zh-CN/index.md @@ -224,7 +224,7 @@ FAQ 语义化版本控制的规范是由 Gravatars 创办者兼 GitHub 共同创办者 [Tom Preston-Werner](http://tom.preston-werner.com) 所建立。 -如果您有任何建议，请到 [GitHub 上提出您的问题](https://github.com/mojombo/semver/issues)。 +如果您有任何建议，请到 [GitHub 上提出您的问题](https://github.com/semver/semver/issues)。 许可证 --- diff --git a/lang/zh-CN/spec/v2.0.0.md b/lang/zh-CN/spec/v2.0.0.md index 5cf025aa..2026fbad 100644 --- a/lang/zh-CN/spec/v2.0.0.md +++ b/lang/zh-CN/spec/v2.0.0.md @@ -224,7 +224,7 @@ FAQ 语义化版本控制的规范是由 Gravatars 创办者兼 GitHub 共同创办者 [Tom Preston-Werner](http://tom.preston-werner.com) 所建立。 -如果您有任何建议，请到 [GitHub 上提出您的问题](https://github.com/mojombo/semver/issues)。 +如果您有任何建议，请到 [GitHub 上提出您的问题](https://github.com/semver/semver/issues)。 许可证 ---