<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 23, 2015 at 7:43 PM, Martin Albisetti <span dir="ltr"><<a href="mailto:martin.albisetti@canonical.com" target="_blank">martin.albisetti@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Option 1 is tempting, since it effectively allows package name<br>
transitions with no need to change the packages themselves, but for<br>
sideloading it's a bit awkwards as you have to provide both a package<br>
and a piece of metadata separately.<br></blockquote><div><br></div><div>Maybe it's also more natural to hook addition of a toplevel name into the review process by adding it to the metadata?</div><div><br></div><div>I find it wouldn't be clear how we identify the app + store namespace metadata combination; would this be a meta-snap? would it have a version? the same version of the original snap might come with and without the toplevel name?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Options 2 and 3 are similar enough, that I think it mostly comes down<br>
to how it affects the pieces identified before. I wouldn't want you to<br>
have been running "apache.beuno.start" for a year, and then suddenly<br>
with an update it stops working because it gets upgraded to<br>
"apache.start".<br></blockquote><div><br></div><div>Perhaps we can simply keep apache.beuno.start even after addition of apache.start</div><div> </div><div>Cheers,</div><div>-- </div><div>Loïc</div></div><br></div></div>