Exceptions to the Update Cycles

A Suggested List of Packages to be Updated Immediately and Made Available in Stable Repositories

Rationale and Definition

Since the monthly update cycle was introduced to AOSC OS in July of 2017 (and later, seasonal update cycles introduced in July 2018), packages which represents feature, and non-bugfix/security updates should first have their build configurations pushed to the staging of the ABBS Tree, uploaded to the [testing] repositories - and made available in the stable repository at the end of each seasonal cycle after testing.

However, given the bugfix/security update may rely - and limited to - on backporting of patches, there are some other packages which could be...

  • Category 1: Hard (or impossible in case of binary packages) to backport security/bugfix patches to, and frequently updated in mixture of feature and security updates. This category is most well represented by (larger) Web browsers, for example, Firefox and Chromium.
  • Category 2: Heavily relied on frequent updates to remain functional. This category is most well represented by tools which reads online APIs/page contents for its basic functionality, for example, youtube-dl.
  • Category 3: Essential to basic Internet access in certain regions. This category is most well represented by network utilities which have to work around new blockades and constraints, for example, shadowsocks.
  • Category 4: AOSC OS distribution-specific development toolkits, which should be the newest at all times.

Exception List

The list below is a concrete and specific list of packages which could be considered as a part of the exception list - meaning that these packages' build configurations could be pushed to the bugfix branch, as a part of the effort to fix "bugs" (non-functional) or "security issues", and made available in the stable repositories after internal testing - regardless of the version changes, and whether new features are to be introduced.

Project Name Package Name Category
Brave Browser brave-browser 1
Chromium chromium 1
Google Chrome google-chrome 1
Intel Processor Microcode Data File intel-ucode 1
Mozilla Firefox firefox 1
OpenJDK openjdk 1
Opera opera 1
Pale Moon palemoon 1
SeaMonkey seamonkey 1
Thunderbird thunderbird 1
Vivaldi vivaldi 1
Flash Player PepperAPI Plugin flashplayer-ppapi 1
AOSC OS AppStream Data aosc-appstream-data 2
Baidu Cloud Client bcloud 2
BiliDan bilidan 2
PyTZ pytz 2
Time Zone Data tzdata 2
AOSC U-Boot Utilities u-boot-aosc-utils 2
You-Get you-get 2
Youtube-DL youtube-dl 2
Gost gost 3
KCPTUN kcptun 3
Lantern lantern 3
OBFS Proxy obfsproxy 3
OBFS4 Proxy obfs4proxy 3
OpenSwan openswan 3
OpenVPN openvpn 3
PCAP-DNSProxy pcap-dnsproxy 3
Shadowsocks shadowsocks 3
Shadowsocks-LibEv shadowsocks-libev 3
Shadowsocks-Qt5 shadowsocks-qt5 3
Simple-OBFS simple-obfs 3
StrongSwan strongswan 3
Tor tor 3
Trojan trojan 3
V2Ray v2ray 3
WireGuard wireguard 3
CA Certificates ca-certs 3
ACBS acbs 4
Ciel ciel 4

Extra Notes

  • Ask: Should non-security updates to packages found in the exception list be committed to the bugfix branch. e.g. Firefox 56.0.2?
    • Re.: No, only if it fits within the five categories discussed above - however, it could be a valid argument that for example, if it prevents a user from accessing a certain website or it leads to crashes - in that case, an update to Firefox should be committed to the bugfix branch and made available after internal testing. So that said, if the bugfix is minor and unlikely to be triggered, the update should still be limited to the staging branch, and made available by the end of a monthly cycle.