552888 - Offer major updates before minor updates when multiple updates are found

Status: RESOLVED DUPLICATE of bug 358108

(Toolkit :: Application Update, defect)

Description

[Robert Strong (they/them - no direct email)]

I had a discussion with beltzner the other day about this. As it stands now aus only offers one update but with this they could offer multiple updates and if the major update had the showNeverForVersion attribute in the update xml they would be notified of the minor update within 24 hours without aus having to change the update xml.

beltzner, does this still sound like the right thing to do?

Comment 1

[Robert Strong (they/them - no direct email)]

There have been a few bugs / complaints in the past about having to first upgrade to the latest minor to then upgrade to the major that I think are totally legit that fixing this would at the very least mitigate. If I am more than one update behind the latest minor then I would have to download to complete mar files to get to the latest which is imo a bad experience.

Comment 2

[Joey Twiddle]

Not knowing any of the inner workings, is it possible there is an advantage to doing minor updates first?

For example, if a refactor requires that some preferences be renamed after an update, there will be some migration code to check and perform this.  This could go in the next minor version IFF that version is guaranteed to be installed.  If it is not guaranteed, then the migration code needs to remain in all future versions of the app, in case a user does not run the app for months and then jumps many updates at once!

Perhaps required stepping-stone versions are already enforced somehow, to deal with issues like this.  Just a thought to consider.

Comment 3

[Robert Strong (they/them - no direct email)]

(In reply to joey from comment #2)
> Not knowing any of the inner workings, is it possible there is an advantage
> to doing minor updates first?
> 
> For example, if a refactor requires that some preferences be renamed after
> an update, there will be some migration code to check and perform this. 
> This could go in the next minor version IFF that version is guaranteed to be
> installed.  If it is not guaranteed, then the migration code needs to remain
> in all future versions of the app, in case a user does not run the app for
> months and then jumps many updates at once!
> 
> Perhaps required stepping-stone versions are already enforced somehow, to
> deal with issues like this.  Just a thought to consider.
No, there isn't an advantage.