[OpenWrt-Devel] [RFC] use Debian like release channel identifiers?

Paul Spooren mail at aparcar.org
Mon Aug 26 19:19:13 EDT 2019

On 25.08.19 22:08, Bjørn Mork wrote:
> Paul Spooren <mail at aparcar.org> writes:
>> as 19.07 is *just around the corner* I was wondering if there's a
>> better way of distinguishing between versions.
>> Right now, I see 4 different *channels* which somewhat match the
>> Debian style, therefore a possible mapping:
>> 18.06.N -> stable
>> 19.07-rcN -> testing
>> 19.07-SNAPSHOT -> unstable
>> SNAPSHOT -> experimental
> This looks fine right now.  But such mappings tend to confuse users over
> time, when "stable" suddenly is redefined to 19.07.1, 22.09.1 etc.  And
> what do you call 18.06.97 when 22.09.1 is "stable"?

I guess that's a good point, how to handle multiple stable (point) 
releases at the same time? I'd think a user running 20.5.2 should be 
offered to upgrade to 21.0.1 and 20.5.3. Whereas the former is 
recommended, not?

> Debian had a long discussion about dropping code names in favour of
> release versions recently See:
> https://lwn.net/Articles/792646/

Thanks for the article. Looking at some vendor implementations, they 
offer something like a stable and beta channel, where the stable channel 
also "suddenly" changes once a new release appears. Isn't that desired 
to keep users with the latest software?

Applying the schema mentioned above, I'd suggest the following upgrade 

* (stable) point upgrades to newer point releases or major release, but 
only one major at a time. (not 19.01 to 20.01 but to 19.07 first).

* (testing) rc upgrade to newest point or rc release, but also max one 
in between. So 19.07-rc2 to 19.07-rc3 or 20.01-rc1.

* (unstable) release snapshot to whatever newest release snapshot, rc or 
point. Upgrading from snap to rc can be based on revision.

* (experimental) snapshot to whatever revision snapshot is more recent

As two releases are planed per year, I see it necessary to simplify the 
upgrade process between those.

> I am not sure if they have reached any conclusion.  But I believe we
> should think about the possible drawbacks here before deciding to change
> the release naming yet again.  I for one would prefer any scheme which
> lasted more than 2 releases....

Very right :)


openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list