mail archive of the rauc mailing list
 help / color / mirror / Atom feed
* [RAUC] Backwards/forwards compatibility of bundle format
@ 2020-06-04 19:02 Matt Campbell
  2020-06-05  6:24 ` Jan Lübbe
  0 siblings, 1 reply; 3+ messages in thread
From: Matt Campbell @ 2020-06-04 19:02 UTC (permalink / raw)
  To: rauc


[-- Attachment #1.1: Type: text/plain, Size: 658 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1024 bytes --]

[-- Attachment #2: Type: text/plain, Size: 66 bytes --]

_______________________________________________
RAUC mailing list

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RAUC] Backwards/forwards compatibility of bundle format
  2020-06-04 19:02 [RAUC] Backwards/forwards compatibility of bundle format Matt Campbell
@ 2020-06-05  6:24 ` Jan Lübbe
  2020-06-05 20:30   ` Matt Campbell
  0 siblings, 1 reply; 3+ messages in thread
From: Jan Lübbe @ 2020-06-05  6:24 UTC (permalink / raw)
  To: Matt Campbell, rauc

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RAUC] Backwards/forwards compatibility of bundle format
  2020-06-05  6:24 ` Jan Lübbe
@ 2020-06-05 20:30   ` Matt Campbell
  0 siblings, 0 replies; 3+ messages in thread
From: Matt Campbell @ 2020-06-05 20:30 UTC (permalink / raw)
  To: Jan Lübbe; +Cc: rauc

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]

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übbe <jlu@pengutronix.de> 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
>
>

-- 
Matthew Campbell
Senior Embedded Systems Engineer
mcampbell@izotope.com

iZotope, Inc.
www.izotope.com

[-- Attachment #2: Type: text/html, Size: 3453 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-06-05 20:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-04 19:02 [RAUC] Backwards/forwards compatibility of bundle format Matt Campbell
2020-06-05  6:24 ` Jan Lübbe
2020-06-05 20:30   ` Matt Campbell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox