openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Mon, Apr 9, 2012 at 12:40 PM, Justin Santa Barbara
<justin@xxxxxxxxxxxx>wrote:

> On Mon, Apr 9, 2012 at 8:18 AM, Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx
> > wrote:
>
>> I'm thinking of the os prefix as standing for OpenStack, not Operating
>>> System.
>>>
>>
>> I would never have guessed that from the context. Why OpenStack instead
>> of Operating System?
>>
>
> We reserve this limited region of the namespace (openstack.org: or os:)
> for keys that we agree to have general meaning.  In return for not using
> that prefix for their own purposes, anyone uploading images knows that
> there will no collisions, no matter what cloud that image lands on, and no
> matter what additional values openstack.org defines in the future.
>

That makes sense.


>
> In general, I'd suggest that prefixing custom properties with your domain
> name is "a good idea" for the long term, but that's a separate issue.
>
> Sounds like you'd prefer openstack.org:version or openstack.org:os_version.
>  Both work for me, I think I prefer the second.
>

I do, too.


>
>
>> Are the major and minor numbers going to be sufficient versioning
>> information? See for example PEP 386 for more detailed version strings (
>> http://www.python.org/dev/peps/pep-0386/).
>>
>
> For a distro, I believe yes.  Do you have a counter-example?
>

Not off the top of my head, but I really only use RedHat variants or Ubuntu
variants, so I thought I would bring it up in case there are others that
use different schemes. For example, how about pre-releases?


>
>   The package names may vary depending on the platform, so the names
>> probably shouldn't be tied to the names of the packages themselves but to
>> the projects. Or maybe that's just a taxonomy problem that should be left
>> up to the taggers.
>>
>
> Absolutely.  The package name would be meaningful/comparable only after
> the distro/major/minor combo.  I can't imagine any distro changing package
> names within a release.  So we really do defer this issue to the distro.
>

It seems suboptimal, but I guess it's reasonable to expect the caller of
the API to be able to provide the distro-specific package name for the
application or library they want included in the image.