ຂໍ້ກຳນົດການຕັ້ງຊື່ສາຂາ (Branch-naming convention)¶

ຂໍ້ກຳນົດການຕັ້ງຊື່ສາຂາຂອງພວກເຮົາຮັບປະກັນວ່າຊອບແວສາມາດຖືກສ້າງ (build) ໂດຍ CI ຂອງພວກເຮົາ ແລະ ທົດສອບໄດ້ງ່າຍໂດຍນັກພັດທະນາຄົນອື່ນໆ.

ໄຟລ໌ README ຂອງ Git repository ທຸກອັນຄວນລະບຸວ່າໃຊ້ຂໍ້ກຳນົດການຕັ້ງຊື່ສາຂາແບບໃດ ແລະ ມີອັນໃດທີ່ແຕກຕ່າງໄປຈາກມາດຕະຖານ.

ແພັກເກດ Click¶

ຊອບແວທີ່ແຈກຢາຍສະເພາະເປັນແພັກເກດ click (ແລະ ບໍ່ແມ່ນເປັນ DEB) ຈະໃຊ້ພຽງແຕ່ສາຂາ master ດຽວທີ່ຖືກປ້ອງກັນໄວ້. ສາຂາການພັດທະນາຊົ່ວຄາວທີ່ແຍກຕ່າງຫາກພ້ອມຊື່ທີ່ອະທິບາຍຕາມໃຈມັກ ສາມາດຖືກສ້າງຂຶ້ນ ແລະ ລວມ (merge) ເຂົ້າສູ່ master ເມື່ອເຖິງເວລາ. ຕາມທີ່ເໝາະສົມ ຄວນໃຊ້ Git tags ຫຼື GitHub releases ເພື່ອໝາຍ ແລະ ເກັບຮັກສາຈຸດໝາຍສຳຄັນໃນປະຫວັດການພັດທະນາ.

ແພັກເກດ DEB¶

ເພື່ອຊ່ວຍໃຫ້ພວກເຮົາສົ່ງໂຄ້ດເຂົ້າສູ່ Ubuntu Touch ໄດ້ຢ່າງສະດວກທີ່ສຸດເທົ່າທີ່ຈະເປັນໄປໄດ້, CI ຂອງພວກເຮົາຈະສ້າງ Git repositories ເປັນ APT archives ຫຼາຍໆອັນໂດຍອັດຕະໂນມັດ ເຊິ່ງໂຮສຢູ່ທີ່ http://repo.ubports.com/, ໂດຍອີງຕາມຊື່ສາຂາ.

ພວກເຮົາຮັກສາສາຂາຕໍ່ໄປນີ້ໃນທົ່ວ Git repositories:

ສາຂາ Git	ຄຳອະທິບາຍ	APT archives ທີ່ກ່ຽວຂ້ອງ
ສາຂາ Git	ຄຳອະທິບາຍ	ຊື່	Distro ພື້ນຖານ
`main`, `ubports/latest`	ສະແດງເຖິງການພັດທະນາຫຼ້າສຸດຂອງ Ubuntu Touch. ການປ່ຽນແປງທຸກປະເພດແມ່ນອະນຸຍາດໃຫ້ມີໃນສາຂານີ້.	`devel-<Ubuntu LTS>` (ເຊັ່ນ: `devel-noble`)	Ubuntu LTS ຫຼ້າສຸດ ຫຼື ທີ່ກຳລັງຈະມາເຖິງ.
`main`, `ubports/latest`		`devel-debian`	Debian testing.
`ubports/<major version>.x` (ເຊັ່ນ: `ubports/24.6.x`)	ສະແດງເຖິງໂຄ້ດໃນເວີຊັນຫຼັກສະເພາະໃດໜຶ່ງ. ມັນແຍກສາຂາອອກຈາກສາຂາ `main` ກ່ອນການປ່ອຍເວີຊັນຫຼັກ, ແລະ ຈະກາຍເປັນສ່ວນໜຶ່ງຂອງການປ່ອຍເວີຊັນຂອງເວີຊັນຫຼັກນັ້ນ. ສະເພາະການແກ້ໄຂບັກ ແລະ ການປ່ຽນແປງທີ່ບໍ່ເຮັດໃຫ້ລະບົບເສຍຫາຍ (non-breaking changes) ເທົ່ານັ້ນທີ່ໄດ້ຮັບອະນຸຍາດໃນສາຂານີ້.	`<major version>.x` (ເຊັ່ນ: `24.6.x`)	Ubuntu LTS ໃນເວລາທີ່ແຍກສາຂາ.
`ubports/focal`	ກໍລະນີພິເສດຂອງ `ubports/<major version>.x`, ເຊິ່ງຖືກແຍກສາຂາຫຼັງຈາກການປ່ອຍ Ubuntu Touch 20.04 OTA-4.	`focal`	Ubuntu 20.04 LTS.
`ubports/focal_-_<ext>`	ສາຂາທີ່ໃຊ້ລະບົບ "branch extensions" ທີ່ຍົກເລີກແລ້ວ ສຳລັບການປ່ຽນແປງຂ້າມອົງປະກອບ. ບໍ່ແນະນຳໃຫ້ໃຊ້ອີກຕໍ່ໄປ.	`focal_-_<ext>`	Ubuntu 20.04 LTS.
`personal/<user>/<name>`, ແລະ ສາຂາອື່ນໆ.	ສາຂາອື່ນໆທັງໝົດອາດຖືກນຳໃຊ້ເພື່ອສະເໜີ merge requests ຫຼື ດ້ວຍເຫດຜົນອື່ນໆ. ສາຂາເຫຼົ່ານີ້ຈະບໍ່ຖືກສ້າງໂດຍ CI ເວັ້ນເສຍແຕ່ວ່ວ່າຈະຖືກສະເໜີເປັນ merge request.	N/A, ເວັ້ນເສຍແຕ່ວ່ວ່າຈະຖືກສະເໜີເປັນ MR ຕໍ່ກັບສາຂາທີ່ກ່າວມາຂ້າງເທິງ (ເບິ່ງລຸ່ມນີ້).

ເພື່ອຮັບປະກັນວ່າສາຂາ main ບໍ່ພາດການປ່ຽນແປງໃດໆ, ທຸກການປ່ຽນແປງຕ້ອງເຮັດກັບສາຂາ main ກ່ອນ ແລ້ວຈຶ່ງ backport ໄປຍັງສາຂາການປ່ອຍເວີຊັນຫຼັກ. ຂໍ້ຍົກເວັ້ນແມ່ນເມື່ອການປ່ຽນແປງບໍ່ສາມາດໃຊ້ໄດ້ກັບສາຂາ main ອີກຕໍ່ໄປເນື່ອງຈາກມີການປ່ຽນແປງອື່ນໆໃນສາຂານັ້ນ.

Note

ຖ້າເວີຊັນການພັດທະນາຕໍ່ໄປຍັງບໍ່ພ້ອມໃຫ້ທົດສອບເທື່ອ, ແລະ ທ່ານຕ້ອງການໃຫ້ການປ່ຽນແປງນັ້ນພ້ອມສຳລັບການຕິດຕັ້ງເພື່ອທົດສອບ, ອະນຸຍາດໃຫ້ກຳນົດເປົ້າໝາຍ changeset ໄປຍັງສາຂາເວີຊັນຫຼັກຊົ່ວຄາວໄດ້ ເພື່ອໃຫ້ໄດ້ແພັກເກດທີ່ສ້າງຂຶ້ນສຳລັບເວີຊັນນັ້ນ. ເມື່ອ changeset ພ້ອມທີ່ຈະ merge, changeset ດັ່ງກ່າວຕ້ອງຖືກປ່ຽນເປົ້າໝາຍກັບໄປທີ່ສາຂາ main.

APT archives ສຳລັບ Merge Requests¶

ນອກເໜືອຈາກ archives ທີ່ກ່າວມາຂ້າງເທິງແລ້ວ, ພວກເຮົາຍັງສ້າງ APT archives ສຳລັບ MRs ທີ່ເຮັດຕໍ່ Git repositories ຂອງພວກເຮົາ. ສິ່ງນີ້ຊ່ວຍໃຫ້ພວກເຮົາທົດສອບຜົນຂອງການ build ໃນອຸປະກອນຕົວຈິງໄດ້ໂດຍໃຊ້ ubports-qa ກ່ອນທີ່ຈະ merge ໂຄ້ດ. ສຳລັບແຕ່ລະ MR, CI ຈະ build ໂຄ້ດຕໍ່ກັບເປົ້າໝາຍດຽວກັນທັງໝົດກັບສາຂາເປົ້າໝາຍຂອງ MR, ແລະ ຈາກນັ້ນຈະຕື່ມ _-_PR_<repository name>_<MR number> ໃສ່ທາງທ້າຍພວກມັນ [1]. ຕົວຢ່າງ:

MR ໝາຍເລກ 100 ທີ່ເຮັດຕໍ່ສາຂາ main ຂອງ Git repository lomiri (ເມື່ອ Ubuntu LTS ປະຈຸບັນແມ່ນ noble) ຈະມີ APT archives ຊື່ວ່າ devel-noble_-_PR_lomiri_100 ແລະ devel-debian_-_PR_lomiri_100.
MR ໝາຍເລກ 125 ທີ່ເຮັດຕໍ່ສາຂາ ubports/24.6.x ຂອງ Git repository morph-browser ຈະມີ APT archive ຊື່ວ່າ 24.6.x_-_PR_morph-browser_125.