Top-level package names, UX questions

[Sergio Schvezov]

On lunes 16 de marzo de 2015 15h'02:33 ART, Mark Shuttleworth wrote:
> On 16/03/15 08:22, Michael Vogt wrote:
>> 4) We also have the option that the package name in the
>> meta/package.yaml is the name in the store. So either "apache.beuno"
>> or "apache". That of course means that in order for a package to
>> become a top-level namespace package it needs to be re-uploaded once
>> with the new name "apache" and there is no automatic transition
>
> The package.developer namespace allows us to have many versions of the
> same package from different developers installed at the same time.
>
> This will almost certainly not work for frameworks, however, which are
> typically mediating a shared resource between apps.
>
> So, if we can't guarantee that you can always have package.dev-a and
> package.dev-b co-installed, perhaps it would be better not to allow that
> altogether? If we said you can ONLY have one version of "package"
> installed on a system at a time, lots of things get easier ("it's always
> just apache.command") and some things get harder ("you can't have both
> the mainline and a sideline version installed at the same time").
>
> I'm leaning towards saying that developer versions would conflict with
> mainline versions - for a device, pick one or the other. I can't
> recalled why we went the other way, now, in prior discussions. Could
> someone remind me of the rationale, or make the case from first
> principles, for having both "apache" and "apache.beuno" installed on the
> same device at the same time?

So we have two guidelines we can follow for the package name:
- packagename.developername
- namespace

I seems we have been going along with packagename being a namespace, 
something that would allow for there to be no collisions. The former forces 
us in a conflict resolution scheme and also makes the _namespace_ itself 
irrelevant.

I do honestly prefer the former as it allows me to create bash.sergiusens 
which just feeds off bash.org and mvo to create bash.mvo to get the shell 
he likes and there is no confusion.

Taking it a bit further, the developer's version can be something 
completely different and there's nothing stopping or forcing him to that, 
if it were otherwise, it would be first come, first served.

I do want to have top level namespaces (namespaces without a developer 
name) but not have packagename.developername be promoted to packagename and 
switchable between the others as it will be too confusing for users.

Making apps coinstallable is great too, as a user I wouldn't need to 
perform strange snappy system commands to get something done (like 
scripting something expecting scripter.ogra instead of scripter.jdstrand or 
scripter even)

Cheers
Sergio