Thank you for doing all this.

Despite official version update policy...
Is there any reason why this should be a Backport rather than a straight update? Our willingness to release straight new-version updates depends much on packager willingness - which you have done. Backports look most necessary if the new version is not compatible with the old.
Having looked at the release notes, the only iffy bits were:

New API:
gnc:accounts-and-all-descendants-sorted
gnc-accounts-and-all-descendantsNone
 which look like additions;

Deprecations:
gnc:account-path-less-p
gnc:accounts-and-all-descendants
 which do not yet remove them.

but both anodine.

BTW Do you use GnuCash and if so, tested this new version?

CC: (none) => lewyssmith

I casually use GnuCash: Hope to use it properly now my personal situation has changed. I have only used a small test data on this new version.

Given there's no real 'security' update features, unless users have an issue, there's little reason to update unless they want new features. So stability vs. risk breaking on update seems a bit one sided.

I believe years ago when I first started as apprentice packager, new releases of GnuCash went into updates

So it appears, historically we've gone against official updates policy.

This is always controversial. I take a simplistic view: if it does not mess up anything, why not push it as a regular update? But your point is valid: "unless users have an issue, there's little reason to update"; let sleeping dogs lie. This applies to many things, yet we do get a fair number of bugs saying just "please update xxx to newest version", usually for both bug fixes & new features. And these are usually honoured, even for Mageia 8 if requested.

My caution about Backports is that nobody will find the new version - unless they know it is there, and specifically look for it (enable Backports). In any event, it is in Cauldron so will land up in Mageia 9.

But this is your baby, so leaving you to choose the path you want (as-is, Backports_testing; or Updates_testing). Please then assign it to QA (qa-bugs).
I do not think Backports have advisories.
And thank you again for your work on this.

Thanks Lewis.

Given where we are in Mageia 8, I've spoken with a mentor: we will leave in backports, so as not to break anything this late in the cycle.

Moving forward with Mageia 9, I'll attempt to keep a close eye on updates, and keep it more aligned with upstream, lessening the chance of breakages, and we will keep the updates as regular (unless upstream advises otherwise).

As for assigning to QA, do I just change the assignee email to qa-bugs@ml.mageia.org?

Correct, just assign to QA when you think it is ready to test.
We may assign bugs back if needed.

Never used gnucash, so first installed our release version.
I then stumbled on a quirk in urpmi:
Bug 30776 - urpmi fail to install from release media when backport is enabled.

Anyway, update was straight:

$ sudo LC_ALL=C urpmi gnucash-4.11-1.mga8.x86_64
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Backports Testing")
  gnucash                        4.11         1.mga8        x86_64  
  lib64gnucash0                  4.11         1.mga8        x86_64  

Swedish localisation is OK, incl account plan.
Investigated some menus. Help works.

Still no SIE import/export (all bookkeeping programs in Sweden have this well defined interoperability, QIF is *not*) so not interesting for me. (if you need this try i.e https://fribok.org/, https://sourceforge.net/projects/jfsaccounting/ - rather stalled development but works, incl invoicing)

CC: (none) => fri

MGA8-64 Plasma on Acer Aspire 5253
At installation from Core/Backports_testing, I noticed that there are more packages involved than the single one listed above. Installed all of them without problems.
Opened an older .gnucash file without problems, did some transactions, and a yearly report, all Worked OK.
I'm not a professional user of gnucash, so loads of all the possibilities are way beyond me.
I used this with the data in an xml file (default choice), but I use it for my own finances storing the data in postgres, but I would have to look around again, because this is not part of the default installation. I cann't do that right now, maybe in a few days.
Leaving it to the experts here wether you want to wait for that, or go ahead with the update.

CC: (none) => herman.viaene

(In reply to xboxboy from comment #4)
> Thanks Lewis.
> 
> Given where we are in Mageia 8, I've spoken with a mentor: we will leave in
> backports, so as not to break anything this late in the cycle.
> 
> Moving forward with Mageia 9, I'll attempt to keep a close eye on updates,
> and keep it more aligned with upstream, lessening the chance of breakages,
> and we will keep the updates as regular (unless upstream advises otherwise).
> 
Once this has been moved to backports, because of Bug 29830 users who install with rpmdrake could very well wind up with this one, anyway.

CC: (none) => andrewsfarm

This one needs to be fixed with proper versioned deps on its libs as found out in bug 30776

never mind, didn't check good enoug, it already is...

Keywords: feedback => (none)

the "bug" comes from  comment 0 not listing all rpms that belongs to this update

I think performed tests are enough for backport.

Regarding the deps, it works to install this backport when backport repo is enabled, and the non-backport version when backport is not enabled.

Keywords: (none) => validated_backport
Whiteboard: (none) => MGA8-64-OK

moved

Resolution: (none) => FIXED
Status: NEW => RESOLVED