[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
behaviors
* (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 :)
Paul
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list