Re: understanding 2025Q2 in aarch64

[Ramiro Aceves <ea1abz%gmail.com@localhost>]

El 13 de agosto de 2025 14:08:27 CEST, Greg Troxel <gdt%lexort.com@localhost> escribió:
>Ramiro Aceves <ea1abz%gmail.com@localhost> writes:
>
>> El 13 de agosto de 2025 12:10:35 CEST, Greg Troxel <gdt%lexort.com@localhost> escribió:
>>>Ramiro Aceves <ea1abz%gmail.com@localhost> writes:
>>>
>>>> Just curious, what technically does trigger the 10.0 ->10.0_2025Q2
>>>> link to be made?
>>>
>>>It's not technical.  It's a human running rm/ln -s.
>>
>> Ok, it is a human running a command, but what is the condition that must be satisfied to decide to issue the command? Just curious.
>
>It's what I said earlier.  It's a judgement that the build is at least
>mostly finished and that the package set is at least mostly ok, such
>that users are better off with the new set, in some fuzzy way taking
>into account an assumed ensemble of users with different concerns.  I
>personally lean to making that decision earlier rather than later,
>weighing fixing security problems over inconvenience.  But I'm not
>involved in aarch64 package builds and lack understanding of the
>details.
>
>> Anyway, from now I think I will always better point to the 202*Q*/All
>> to also prevent for undesired upgrades.
>
>I think that's a perfectly fine thing to do.
>
>> Just the last question. What happens if you upgrade to the for example
>> , 2025Q3 release and some packages do not work, can I return back all
>> the installed packages to 2025Q2 or backwards upgrade is not
>> supported?
>
>I would definitely listen to jperkin.  I would think that changing the
>URL back, pkgin up, pkgin fug, would return you to the previous step,
>and if not it's a bug.   But then you get to keep both halves, figure it
>out, and submit changes to fix the bug.
>
>Backups are wise, always, twice as many as you think you need, unless
>everybody mocks you for too much in which case you might be right.
>
>The other thing you can do if you have a problem is check out the 2025Q3
>branch and fix/build the problematic package.  Staying back is not a
>good long-terms strategy.

Thanks Greg for advice and explanations. I understand it better now.

Regards.
Ramiro