On 25.08.19 22:08, Bjørn Mork wrote:
Paul Spooren <m...@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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
