Terminology cleanup: snaps vs. apps

Sergio Schvezov sergio.schvezov at canonical.com
Wed Jan 6 20:01:22 UTC 2016

On Wed, Jan 6, 2016 at 2:24 PM, Gustavo Niemeyer <
gustavo.niemeyer at canonical.com> wrote:

> Hello snappers, and happy new year!
> This is a short note coming from the terminology room to help us all be on
> the same track.
> In the code base we have several different ways we call a "snap": a part,
> an app, a pkg, and an actual snap. We've been slowly but consistently
> cleaning this up so we have *snap* only.
> To make such terminology discussions even more interesting, though, in the
> recent sprint we decided to get rid of the term "binaries" in the snap
> metadata and replace it with "apps", which officially introduces back the
> term "app", but now meaning a runnable program within a snap.
> Fortunately, this aligns well with the idea that we had a snap type named
> "app" (we also have "os", "kernel", and "gadget" snap types). So an "app"
> snap type has the main purpose of carrying apps. All good on that front.
> Some other corners still need polishing, though, and some of those will
> surface in a visible way to applications. For example, we have the mouthful
> SNAP_APP_USER_DATA_PATH, which has a sparing "app" there meaning nothing.
> I'm hoping we can cut that down to simply SNAP_USER_DATA or similar in the
> coming weeks, with its friends following along.
> We'll send a note about such changes in due time, and will be careful to
> introduce them while preserving compatibility for a while.
> For now, this is just a heads up, and a proposal for us to use the
> terminology consistently in our snappy-related conversations.
Just for reference, I'm adding this link

It describes the internal format that was discussed, needless to say, the
2.x branch of snapcraft is also going to reflect the services/binaries ->
apps change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160106/0fba561a/attachment.html>

More information about the snappy-devel mailing list