From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgv8U-0005QD-R3 for rauc@pengutronix.de; Thu, 04 Jun 2020 21:02:44 +0200 Received: by mail-wr1-x42b.google.com with SMTP id x13so7298550wrv.4 for ; Thu, 04 Jun 2020 12:02:42 -0700 (PDT) MIME-Version: 1.0 From: Matt Campbell Date: Thu, 4 Jun 2020 15:02:30 -0400 Message-ID: Subject: [RAUC] Backwards/forwards compatibility of bundle format List-Id: RAUC Project - Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1501386244==" Errors-To: rauc-bounces@pengutronix.de Sender: "RAUC" To: rauc@pengutronix.de --===============1501386244== Content-Type: multipart/alternative; boundary="000000000000f3cb5b05a746c998" --000000000000f3cb5b05a746c998 Content-Type: text/plain; charset="UTF-8" Hi All, I'm looking into RAUC for a product, and I was wondering if there are any project goals around the stability of the RAUC bundle format. Specifically, it would be great if all future versions of the rauc binary was compatible will all previous bundle formats, and also that all older versions of the binary can install future created bundles. Obviously that's a big ask, but it'd be great to know what to expect of RAUC in the future. Even a rough idea of how compatibility will play out will help me greatly in evaluating RAUC. Best, ~Matt -- Matthew Campbell Senior Embedded Systems Engineer mcampbell@izotope.com iZotope, Inc. www.izotope.com --000000000000f3cb5b05a746c998 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I'm looking into RAUC for a= product, and I was wondering if there are any project goals around the sta= bility of the RAUC bundle format. Specifically, it would be great if all fu= ture versions of the rauc binary was compatible will all previous bundle fo= rmats, and also that all older versions of the binary can install future cr= eated bundles. Obviously that's a big=C2=A0ask, but it'd be great t= o know what to expect of RAUC in the future. Even a rough idea of how compa= tibility=C2=A0will=C2=A0 play out will help me greatly in evaluating RAUC.<= /div>

Best,
~Matt
--
Matthew Campbell
Senior Embedded Systems Engineer

--000000000000f3cb5b05a746c998-- --===============1501386244== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAUC mailing list --===============1501386244==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Message-ID: <0acb7ca57dc256c3149a5426af8dc39350b9cbd8.camel@pengutronix.de> From: Jan =?ISO-8859-1?Q?L=FCbbe?= Date: Fri, 05 Jun 2020 08:24:58 +0200 In-Reply-To: References: MIME-Version: 1.0 Subject: Re: [RAUC] Backwards/forwards compatibility of bundle format List-Id: RAUC Project - Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: rauc-bounces@pengutronix.de Sender: "RAUC" To: Matt Campbell , rauc@pengutronix.de Hi, On Thu, 2020-06-04 at 15:02 -0400, Matt Campbell wrote: > I'm looking into RAUC for a product, and I was wondering if there are > any project goals around the stability of the RAUC bundle format. > Specifically, it would be great if all future versions of the rauc > binary was compatible will all previous bundle formats, and also that > all older versions of the binary can install future created bundles. > Obviously that's a big ask, but it'd be great to know what to expect > of RAUC in the future. Even a rough idea of how compatibility will > play out will help me greatly in evaluating RAUC. The basic bundle format has not changed so far (squashfs with CMS signature), which means that newer versions can install old bundles. Going forward, any issue with installing old bundles would be considered a bug. Newer RAUC versions have introduced new features and slot types, though (such as casync, emmc-boot partitions, MBR partition switching). If you use those features, old versions of RAUC won't be able to install those bundles. As long as you don't use new features, our intention is that bundles created by newer versions will be installable by older versions. There are ideas of introducing a new bundle format to allow streaming installation (over the network), but we won't remove support for the original format. If there are ever reasons that require an incompatible change, you can use a two step migration: You can use an intermediate update to ship a new RAUC binary in a bundle created by the old version. Then use the newly installed RAUC for the real update. Does that answer your questions? Regards, Jan _______________________________________________ RAUC mailing list From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: MIME-Version: 1.0 References: <0acb7ca57dc256c3149a5426af8dc39350b9cbd8.camel@pengutronix.de> In-Reply-To: <0acb7ca57dc256c3149a5426af8dc39350b9cbd8.camel@pengutronix.de> From: Matt Campbell Date: Fri, 5 Jun 2020 16:30:57 -0400 Message-ID: Content-Type: multipart/alternative; boundary="0000000000001d34a505a75c248a" Subject: Re: [RAUC] Backwards/forwards compatibility of bundle format To: =?UTF-8?Q?Jan_L=C3=BCbbe?= Cc: rauc@pengutronix.de List-ID: --0000000000001d34a505a75c248a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jan, That all makes sense and answers my question. Ideally we would like to avoid the intermediate updates as this adds complexity to update logic (i.e. you have to leap-frog through that for devices that are factory fresh). Sounds like there are no immediate plans for breaking changes and I'll keep an eye on the mailing list so I can weigh in. Thank you very much for taking the time to give such a well thought out answer! For anyone else who finds this thread later, I also found reference to this in the documentation https://rauc.readthedocs.io/en/latest/advanced.html#migrating-to-an-updated= -bundle-version . Best, ~Matt On Fri, Jun 5, 2020 at 2:25 AM Jan L=C3=BCbbe wrote: > Hi, > > On Thu, 2020-06-04 at 15:02 -0400, Matt Campbell wrote: > > I'm looking into RAUC for a product, and I was wondering if there are > > any project goals around the stability of the RAUC bundle format. > > Specifically, it would be great if all future versions of the rauc > > binary was compatible will all previous bundle formats, and also that > > all older versions of the binary can install future created bundles. > > Obviously that's a big ask, but it'd be great to know what to expect > > of RAUC in the future. Even a rough idea of how compatibility will > > play out will help me greatly in evaluating RAUC. > > The basic bundle format has not changed so far (squashfs with > CMS > signature), which means that newer versions can install old bundles. > Going forward, any issue with installing old bundles would be > considered a bug. > > Newer RAUC versions have introduced new features and slot types, though > (such as casync, emmc-boot partitions, MBR partition switching). If you > use those features, old versions of RAUC won't be able to install those > bundles. As long as you don't use new features, our intention is that > bundles created by newer versions will be installable by older > versions. > > There are ideas of introducing a new bundle format to allow streaming > installation (over the network), but we won't remove support for the > original format. > > > If there are ever reasons that require an incompatible change, you can > use a two step migration: > You can use an intermediate update to ship a new RAUC binary in a > bundle created by the old version. Then use the newly installed RAUC > for the real update. > > > Does that answer your questions? > > Regards, > Jan > > --=20 Matthew Campbell Senior Embedded Systems Engineer mcampbell@izotope.com iZotope, Inc. www.izotope.com --0000000000001d34a505a75c248a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jan,

That all makes sense and answer= s my question. Ideally we would like to avoid the intermediate updates as t= his adds complexity to update logic (i.e. you have to leap-frog through tha= t for devices that are factory fresh). Sounds like there are no immediate p= lans for breaking changes and I'll keep an eye on the mailing list so I= can weigh in. Thank you very much for taking the time to give such a well = thought=C2=A0out answer!

For anyone else who finds= this thread later, I also found reference=C2=A0to this in the documentatio= n=C2=A0https://rauc.readthedocs.io/en/latest/ad= vanced.html#migrating-to-an-updated-bundle-version.

Best,
~Matt

On Fri, Jun 5, 2020 at 2:25 AM Jan L=C3=BC= bbe <jlu@pengutronix.de> wr= ote:
Hi,

On Thu, 2020-06-04 at 15:02 -0400, Matt Campbell wrote:
> I'm looking into RAUC for a product, and I was wondering if there = are
> any project goals around the stability of the RAUC bundle format.
> Specifically, it would be great if all future versions of the rauc
> binary was compatible will all previous bundle formats, and also that<= br> > all older versions of the binary can install future created bundles. > Obviously that's a big ask, but it'd be great to know what to = expect
> of RAUC in the future. Even a rough idea of how compatibility will > play out will help me greatly in evaluating RAUC.

The basic bundle format has not changed so far (squashfs with
CMS
signature), which means that newer versions can install old bundles.
Going forward, any issue with installing old bundles would be
considered a bug.

Newer RAUC versions have introduced new features and slot types, though
(such as casync, emmc-boot partitions, MBR partition switching). If you
use those features, old versions of RAUC won't be able to install those=
bundles. As long as you don't use new features, our intention is that bundles created by newer versions will be installable by older
versions.

There are ideas of introducing a new bundle format to allow streaming
installation (over the network), but we won't remove support for the original format.


If there are ever reasons that require an incompatible change, you can
use a two step migration:
You can use an intermediate update to ship a new RAUC binary in a
bundle created by the old version. Then use the newly installed RAUC
for the real update.


Does that answer your questions?

Regards,
Jan



--
Matthew Campbell
Senior Emb= edded Systems Engineer

iZotope= , Inc.
--0000000000001d34a505a75c248a--