Terminology cleanup: snaps vs. apps

[Sergio Schvezov]

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
https://docs.google.com/document/d/1U6k0R9NPOyrn6MN16naOEX1BJ-BBzU6qHxMB4Ep_49w/edit#

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>