I could be mistaken, but I think the main reason for upgrading to a
final minor release before each major jump is simply for backwards
compatibility if needed. But if you're proceeding with a backup at each
stage (which should be the case anyway) then one could just revert to a
backup and try again, or be less aggressive on the jump and employ a few
extra steps.
As I understand it, the last minor release, which is usually out
concurrently with the next major release, should be able to still read
the file after the x.0 upgrade.
That is,
2.6.21 should be able to read the file after upgrading to 3.0, but
2.6.12 for example, might not be able to. The same would apply to 3.11
and 4.0, and soon 4.14 and 5.0
The benefit of stopping off at a previous minor release first, would be
if after a few weeks or more, you find a major bug that affects your
particular book or use-case and you need to drop back to the previous
release without having to restore an older backup and lose work. Thus I
think the only one that would really matter for with a several-version
upgrade attempt, would be the upcoming 4.14. You would be able to go
back and forth between 4.x and 5.x as needed. I don't see much point in
being able to need to go back to 2.6.x once you've already jumped to v4.
Regards,
Adrien
On 2/1/23 4:44 AM, Fred Bone wrote:
AIUI the advice is to upgrade to 2.6.21 (i.e. the latest 2.6.*) *first*,
open and save the file, and only *then* upgrade to 3.11 and proceed as
above.
And of course take a backup copy at each stage in case you need to re-do.
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
