On 06/08/2021 09.33, Simon Lees wrote:
On 8/6/21 5:28 AM, Carlos E. R. wrote:
On 05/08/2021 15.39, Philipp Wagner wrote:
Hi Andreas,
...
Good point, but I'm not sure what the solution is. To widen the question a bit: What do we do in Tumbleweed generally in a case where an update requires manual intervention from the user? (In this case *before* the update is actually performed.)
1. Somehow notify the user before doing the update, and giving them a choice to not do the upgrade and e.g. pin the old version.
2. Buy us time by providing two versions of the same software. (I'd note that this solution isn't sustainable long-term, so we'll need to have the discussion about "what then" one way or the other.)
3. Try to come up with a automatic migration solution downstream (in this case, dump the db and try to re-import it).
4. Simply do the upgrade and assume users will somehow deal with it (e.g. under the assumption that "this is Tumbleweed").
5. Do not provide 2.5 as update of 2.4.
Forces manual action to install 2.5 when 2.4 dissapears, but for a limited time both versions should be available. Somehow tell users in an update of 2.4 to 2.4 something that it is end of the road, read some link.
Just some out of the box thinking, I have no idea if it is feasible :-)
This is practically the same as 2, the question is how long can we sustain both if at all.
One month? :-) I don't think it matches #2. My idea is not to buy time, but to force a manual upgrade, as install of a new package. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))