I agree with Kevin on both accounts that ~2 versions upgrade path is a safe bet and we should support 2.1 to 2.5 upgrade.
You may want to talk to Josh and/or the TAMs to see if there's any other upgrade path that we have to worry about from 2.0 and below. I think it's safe to remove support for lower than 2.0. + Al + Gerry to see if I may have missed something from QA side. Regards, Naoki On Fri, Jan 15, 2016 at 6:05 PM, Kevin Grandon <[email protected]> wrote: > I haven't found any documentation on this. I only remember because I asked > around the 2.0 release and it's what product decided on as a policy at the > time. > > It could potentially be different now, though ~2 releases seems like a > reasonable upgrade lifetime to me, and if needed we could always force > multiple upgrade steps for full migration capability. > > Best, > Kevin > > > On Fri, Jan 15, 2016 at 6:03 PM, Kevin Grandon <[email protected]> wrote: > >> I haven't found any documentation on this. I only remember because I >> asked around the 2.0 release and it's what product decided on as a policy >> at the time. >> >> It could potentially be different now, though ~2 releases seems like a >> reasonable upgrade lifetime to me, and if needed we could always force >> multiple upgrade steps for full migration capability. >> >> Best, >> Kevin >> >> On Fri, Jan 15, 2016 at 8:18 AM, Tim Guan-tin Chien <[email protected] >> > wrote: >> >>> Nice! Is this documented somewhere? >>> >>> Kevin Grandon <[email protected]> 於 2016年1月15日 星期五寫道： >>> >>> We previously agreed to support upgrades over two versions at anytime. >>>> E.g., we could support 2.0 -> 2.2 in master, but any migration logic prior >>>> to 2.0 in master could be removed from the code. >>>> >>>> Since the latest branch is 2.5, if nothing has changed we should >>>> support upgrading from 2.1 -> 2.5, but anything <= 2.0 can be removed from >>>> the codebase. >>>> >>>> Best, >>>> Kevin >>>> >>>> On Fri, Jan 15, 2016 at 4:05 AM, Tim Guan-tin Chien < >>>> [email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> With the "pivot to connected devices" and the fact that v1.x devices >>>>> are fall out of partner support, do we still care about the >>>>> possibility of having these profiles being upgraded to v2.6 (current >>>>> master) *directly*? >>>>> >>>>> I am looking at, particularly, preferences saved in mozSettings. >>>>> Dropping those support will help us free up development time on >>>>> supporting future products, and also help us making booting the (even >>>>> brand new phones) faster*. >>>>> >>>>> * See https://bugzilla.mozilla.org/show_bug.cgi?id=1095034; we have >>>>> not exposed things like DB_VERSION to Gaia so Gaia System has too >>>>> check for *every* old keys *everytime* the System boots. At least it >>>>> would have to check a version flag set and we unfortunately have not >>>>> yet concentrate all the migration there ** >>>>> >>>>> ** Like the badly-written keyboard layout migration >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1180607 which no longer >>>>> need to be checked for post 1.3 new phones. >>>>> >>>>> >>>>> Tim >>>>> _______________________________________________ >>>>> dev-fxos mailing list >>>>> [email protected] >>>>> https://lists.mozilla.org/listinfo/dev-fxos >>>>> >>>> >>>> >>> >>> -- >>> (Apologies — sent from mobile) >>> >> >> > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
