add indonesian translation

_config.yml

@@ -9,6 +9,7 @@ languages:
   ru: pyccкий
   es: español
   it: italiano
+  id: indonesia
   pt-BR: português brasileiro
   zh-TW: 繁體中文
   zh-CN: 简体中文

lang/id/index.md

@@ -0,0 +1,164 @@
+---
+title: Versi Semantik 2.0.0
+redirect_from: /lang/id/
+author: Aditya Purwa
+---
+
+Versi Semantik 2.0.0
+==============================
+
+Ringkasan
+-------
+
+Versi semantik ditulis dalam bentuk MAJOR.MINOR.PATCH, dengan:
+
+1. Tambah angka versi MAJOR jika membuat perubahan yang merubah API.
+2. Tambah angka versi MINOR jika menambah fitur tanpa membuat versi lama tidak bisa digunakan.
+3. Tambah angka versi PATCH jika ada perbaikan bug tanpa membuat versi lama tidak bisa digunakan.
+
+Tambahan label dan versi sebelum rilis atau info tambahan tersedia sebagai ekstensi dari format
+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 kebutuhan sistem terlalu ketat, bisa jadi sistem kita tidak bisa dikembangkan
+lagi. Jika spesifikasi kebutuhan sistem terlalu luas, semakin sulit untuk mengatur versi mana
+yang bisa digunakan dengan versi yang lain. Situasi inilah yang disebut dengan "dependency hell".
+
+Sebagai solusi permasalahan ini, saya ajukan sebuah standar yang bisa digunakan sebagai
+dasar untuk menentukan bagaimana cara menentukan versi, dan bagaimana cara menambah angka-angka
+di versi tersebut. Aturan ini hanyalah dasar, dan tidak untuk membatasi standar versi yang 
+sebelumnya sudah digunakan.
+
+Supaya standar ini bisa bermanfaat, pertama kalian harus menentukan API publik, titik
+dimana kalian mulai menggunakan standar ini. Setelah ditentukan, setiap rilis
+versi bisa kalian komunikasikan dengan dokumentasi, dan secara langsung melalui angka versi
+tersebut. Pembetulan bug menambah angka patch, penambahan fitur menambah angka minor, perubahan
+yang membuat versi lama tidak bisa digunakan menambah angka major.
+
+Standar ini bernama "Versi Semantik", dengan standar ini, setiap orang yang melihat
+angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut.
+
+Spesifikasi Versi Semantik (VerSem)
+------------------------------------------
+
+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).
+
+
+1. Perangkat lunak dengan Versi Semantik harus menentukan API public. Bisa
+dijelaskan dengan kode, atau ditulis di dokumentasi, ditulis dengan jelas dan akurat.
+
+2. Versi HARUS ditulis dalam bentuk X.Y.Z, dengan X, Y, Z angka bulat positif, dan TIDAK
+BOLEH didahului angka 0 (contoh 01.02.03). X adalah versi MAJOR, Y adalah minor, dan Z adalah patch.
+
+3. Setelah versi dirilis, isi dari versi tersebut TIDAK BOLEH dirubah. Setiap perubahan harus
+merilis versi baru.
+
+4. Versi major 0 (0.y.z) adalah untuk pengembangan, dan bisa terjadi banyak perubahan. API publik
+dianggap tidak stabil di versi ini.
+
+5. Versi 1.0.0 adalah titik awal API publik, setiap versi baru ditulis berdasarkan versi ini.
+
+6. Versi patch Z (x.y.Z | x > 0) HARUS ditambah jika ada perbaikan bug tanpa menambah fitur.
+
+7. Versi minor Y (x.Y.z | x > 0) HARUS ditambah jika ada fitur baru, atau ada fitur lama
+yang ditandai usang, bisa dirubah bersama dengan versi patch, jika minor ditambahkan, maka versi patch harus dikembalikan ke angka 0.
+
+8. Versi major X (X.y.z | X > 0) HARUS ditambah 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 dirubah bersama dengan versi patch dan minor, jika major ditambahkan, 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. Data tambahan BISA ditulis setelah versi sebelum rilis didahului dengan tanda tambah
+dan bisa dipisah dengan titik. Data tambahan HARUS ditulis dengan huruf ASCII alfanumerik dan garis
+[0-9A-Za-z]. Data tambahan TIDAK BOLEH kosong. Data tambahan 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 data tambahan. 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 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.
+
+Contohnya adalah ada sebuah modul dengan nama "Truk". Modul tersebut butuh dengan modul lain dengan nama "Tangga". Ketika "Truk" dibuat, versi "Tangga" masih dalam 3.1.0. Karena "Truk" menggunakan versi "Tangga" 3.1.0, dengan Versi Semantik, jika ada versi baru, "Truk" bisa dengan yakin masih bisa menggunakan modul "Tangga" selama masih dalam batas dibawah versi 4.0.0.
+
+Versi Semantik adalah standar, dan mungkin bisa diikuti dan tidak diikuti, dan tugas dari standar hanyalah untuk membantu supaya pemberian versi bisa lebih jelas.
+
+Jika standar ini terdengar bagus, kalian bisa mulai menggunakan standar Versi Semantik dan mengikuti aturannya. Tautkan ke website ini supaya orang lain bisa menggunakan standar Versi Semantik juga.
+
+
+Pertanyaan Yang Sering Diajukan
+---
+
+### Bagaimana memulai versi pengembangan 0.y.z?
+
+Paling mudah adalah memulai dengan versi 0.1.0.
+
+### Kapan harus dirilis versi 1.0.0?
+
+Ketika sistem yang dikembangkan sudah stabil dan bisa digunakan di sistem produktif, kalian bisa
+mulai menentukannya dengan versi 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.
+
+### 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?
+
+Ini lebih ke permasalahan pengembangan, jika pengembangan dilakukan dengan seksama, maka seharusnya tidak terjadi perubahan yang terlalu signifikan dalam waktu yang cepat.
+
+### Terlalu merepotkan!
+
+Sudah tanggung jawab bagi pengembang untuk memastikan sistemnya bisa digunakan dengan baik dan mudah. Versi Semantik hanya memandu orang untuk bisa saling seragam dan bisa bekerja sama dengan baik.
+
+### Bagaimana jika secara tidak sengaja membuat perubahan yang menjadikan versi lama tidak bisa dipakai?
+
+Langsung rubah perubahan tersebut dan kembalikan supaya masih bisa digunakan versi lama dan tambahkan versi minor.
+
+### Bagaimana jika saya merubah kebutuhan sistem tanpa merubah 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.
+
+### Bagaimana jika perubahan yang terjadi ternyata sangat besar dan sudah dirilis di versi 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.
+
+### Bagaimana jika ada fitur yang usang?
+
+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.
+
+### 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.
+
+Tentang
+-----
+
+Spesifikasi Versi Semantik dibuat oleh [Tom
+Preston-Werner](http://tom.preston-werner.com), pembuat Gravatars dan
+cofounder dari GitHub.
+
+Translasi Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com).
+
+Untuk saran dan kritik, [buka issue di GitHub](https://github.com/mojombo/semver/issues).
+
+
+Lisensi
+-------
+
+[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)

lang/id/spec/v2.0.0.md

@@ -0,0 +1,164 @@
+---
+title: Versi Semantik 2.0.0
+redirect_from: /lang/id/
+author: Aditya Purwa
+---
+
+Versi Semantik 2.0.0
+==============================
+
+Ringkasan
+-------
+
+Versi semantik ditulis dalam bentuk MAJOR.MINOR.PATCH, dengan:
+
+1. Tambah angka versi MAJOR jika membuat perubahan yang merubah API.
+2. Tambah angka versi MINOR jika menambah fitur tanpa membuat versi lama tidak bisa digunakan.
+3. Tambah angka versi PATCH jika ada perbaikan bug tanpa membuat versi lama tidak bisa digunakan.
+
+Tambahan label dan versi sebelum rilis atau info tambahan tersedia sebagai ekstensi dari format
+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 kebutuhan sistem terlalu ketat, bisa jadi sistem kita tidak bisa dikembangkan
+lagi. Jika spesifikasi kebutuhan sistem terlalu luas, semakin sulit untuk mengatur versi mana
+yang bisa digunakan dengan versi yang lain. Situasi inilah yang disebut dengan "dependency hell".
+
+Sebagai solusi permasalahan ini, saya ajukan sebuah standar yang bisa digunakan sebagai
+dasar untuk menentukan bagaimana cara menentukan versi, dan bagaimana cara menambah angka-angka
+di versi tersebut. Aturan ini hanyalah dasar, dan tidak untuk membatasi standar versi yang 
+sebelumnya sudah digunakan.
+
+Supaya standar ini bisa bermanfaat, pertama kalian harus menentukan API publik, titik
+dimana kalian mulai menggunakan standar ini. Setelah ditentukan, setiap rilis
+versi bisa kalian komunikasikan dengan dokumentasi, dan secara langsung melalui angka versi
+tersebut. Pembetulan bug menambah angka patch, penambahan fitur menambah angka minor, perubahan
+yang membuat versi lama tidak bisa digunakan menambah angka major.
+
+Standar ini bernama "Versi Semantik", dengan standar ini, setiap orang yang melihat
+angka versi bisa tahu secara umum apa yang berubah dengan sistem tersebut.
+
+Spesifikasi Versi Semantik (VerSem)
+------------------------------------------
+
+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).
+
+
+1. Perangkat lunak dengan Versi Semantik harus menentukan API public. Bisa
+dijelaskan dengan kode, atau ditulis di dokumentasi, ditulis dengan jelas dan akurat.
+
+2. Versi HARUS ditulis dalam bentuk X.Y.Z, dengan X, Y, Z angka bulat positif, dan TIDAK
+BOLEH didahului angka 0 (contoh 01.02.03). X adalah versi MAJOR, Y adalah minor, dan Z adalah patch.
+
+3. Setelah versi dirilis, isi dari versi tersebut TIDAK BOLEH dirubah. Setiap perubahan harus
+merilis versi baru.
+
+4. Versi major 0 (0.y.z) adalah untuk pengembangan, dan bisa terjadi banyak perubahan. API publik
+dianggap tidak stabil di versi ini.
+
+5. Versi 1.0.0 adalah titik awal API publik, setiap versi baru ditulis berdasarkan versi ini.
+
+6. Versi patch Z (x.y.Z | x > 0) HARUS ditambah jika ada perbaikan bug tanpa menambah fitur.
+
+7. Versi minor Y (x.Y.z | x > 0) HARUS ditambah jika ada fitur baru, atau ada fitur lama
+yang ditandai usang, bisa dirubah bersama dengan versi patch, jika minor ditambahkan, maka versi patch harus dikembalikan ke angka 0.
+
+8. Versi major X (X.y.z | X > 0) HARUS ditambah 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 dirubah bersama dengan versi patch dan minor, jika major ditambahkan, 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. Data tambahan BISA ditulis setelah versi sebelum rilis didahului dengan tanda tambah
+dan bisa dipisah dengan titik. Data tambahan HARUS ditulis dengan huruf ASCII alfanumerik dan garis
+[0-9A-Za-z]. Data tambahan TIDAK BOLEH kosong. Data tambahan 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 data tambahan. 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 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.
+
+Contohnya adalah ada sebuah modul dengan nama "Truk". Modul tersebut butuh dengan modul lain dengan nama "Tangga". Ketika "Truk" dibuat, versi "Tangga" masih dalam 3.1.0. Karena "Truk" menggunakan versi "Tangga" 3.1.0, dengan Versi Semantik, jika ada versi baru, "Truk" bisa dengan yakin masih bisa menggunakan modul "Tangga" selama masih dalam batas dibawah versi 4.0.0.
+
+Versi Semantik adalah standar, dan mungkin bisa diikuti dan tidak diikuti, dan tugas dari standar hanyalah untuk membantu supaya pemberian versi bisa lebih jelas.
+
+Jika standar ini terdengar bagus, kalian bisa mulai menggunakan standar Versi Semantik dan mengikuti aturannya. Tautkan ke website ini supaya orang lain bisa menggunakan standar Versi Semantik juga.
+
+
+Pertanyaan Yang Sering Diajukan
+-------------------------------
+
+### Bagaimana memulai versi pengembangan 0.y.z?
+
+Paling mudah adalah memulai dengan versi 0.1.0.
+
+### Kapan harus dirilis versi 1.0.0?
+
+Ketika sistem yang dikembangkan sudah stabil dan bisa digunakan di sistem produktif, kalian bisa
+mulai menentukannya dengan versi 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.
+
+### 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?
+
+Ini lebih ke permasalahan pengembangan, jika pengembangan dilakukan dengan seksama, maka seharusnya tidak terjadi perubahan yang terlalu signifikan dalam waktu yang cepat.
+
+### Terlalu merepotkan!
+
+Sudah tanggung jawab bagi pengembang untuk memastikan sistemnya bisa digunakan dengan baik dan mudah. Versi Semantik hanya memandu orang untuk bisa saling seragam dan bisa bekerja sama dengan baik.
+
+### Bagaimana jika secara tidak sengaja membuat perubahan yang menjadikan versi lama tidak bisa dipakai?
+
+Langsung rubah perubahan tersebut dan kembalikan supaya masih bisa digunakan versi lama dan tambahkan versi minor.
+
+### Bagaimana jika saya merubah kebutuhan sistem tanpa merubah 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.
+
+### Bagaimana jika perubahan yang terjadi ternyata sangat besar dan sudah dirilis di versi 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.
+
+### Bagaimana jika ada fitur yang usang?
+
+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.
+
+### 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.
+
+Tentang
+-----
+
+Spesifikasi Versi Semantik dibuat oleh [Tom
+Preston-Werner](http://tom.preston-werner.com), pembuat Gravatars dan
+cofounder dari GitHub.
+
+Translasi Bahasa Indonesia ditulis oleh [Aditya Purwa](https://adityamyria.wordpress.com).
+
+Untuk saran dan kritik, [buka issue di GitHub](https://github.com/mojombo/semver/issues).
+
+
+Lisensi
+-------
+
+[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)