Open Stack

On 2/10/15, 10:35, "Alexander Tivelkov" <ativelkov at mirantis.com> wrote:

>Thanks Monty!
>
>Yup, probably I've missed that. I was looking at pbr and its version
>implementation, but didn't realize that this is actually a fusion of
>semver and pep440.
>
>So, we have this as an extra alternative to choose from.
>
>It would be an obvious choice if we were just looking for some common
>solution to version objects within openstack. However, I am a bit
>concerned about applying it to Artifact Repository. As I wrote before,
>we are trying to make the Repository to be language- and
>platform-agnostic tool for other developers, including the ones
>originating from non-python and non-openstack worlds. Having a
>versioning notation which is non-standard for everybody but openstack
>developers does not look like a good idea to me.
>--
>Regards,
>Alexander Tivelkov
>
>
>On Tue, Feb 10, 2015 at 6:55 PM, Monty Taylor <mordred at inaugust.com>
>wrote:
>> On 02/10/2015 10:28 AM, Alexander Tivelkov wrote:
>>> Hi folks,
>>>
>>> One of the key features that we are adding to Glance with the
>>> introduction of Artifacts is the ability to have multiple versions of
>>> the same object in the repository: this gives us the possibility to
>>> query for the latest version of something, keep track on the changes
>>> history, and build various continuous delivery solutions on top of
>>> Artifact Repository.
>>>
>>> We need to determine the format and rules we will use to define,
>>> increment and compare versions of artifacts in the repository. There
>>> are two alternatives we have to choose from, and we are seeking advice
>>> on this choice.
>>>
>>> First, there is Semantic Versioning specification, available at [1].
>>> It is a very generic spec, widely used and adopted in many areas of
>>> software development. It is quite straightforward: 3 mandatory numeric
>>> components for version number, plus optional string labels for
>>> pre-release versions and build metadata.
>>>
>>> And then there is PEP-440 spec, which is a "recommended approach to
>>> identifying versions and specifying dependencies when distributing
>>> Python". It is a "pythonic" way to set versions of python packages,
>>> including PIP version strings.
>>>
>>> Conceptually PEP-440 and Semantic Versioning are similar in purpose,
>>> but slightly different in syntax. Notably, the count of version number
>>> components and rules of version precedence resolution differ between
>>> PEP-440 and SemVer. Unfortunately, the two version string formats are
>>> not compatible, so we have to choose one or the other.
>>>
>>> According to my initial vision, the Artifact Repository should be as
>>> generic as possible in terms of potential adoption. The artifacts were
>>> never supposed to be python packages only, and even the projects which
>>> will create and use these artifacts are not mandatory limited to be
>>> pythonic, the developers of that projects may not be python
>>> developers! So, I'd really wanted to avoid any python-specific
>>> notations, such as PEP-440 for artifacts.
>>>
>>> I've put this vision into a spec [3] which also contains a proposal on
>>> how to convert the semver-compatible version strings into the
>>> comparable values which may be mapped to database types, so a database
>>> table may be queried, ordered and filtered by the object version.
>>>
>>> So, we need some feedback on this topic. Would you prefer artifacts to
>>> be versioned with SemVer or with PEP-440 notation? Are you interested
>>> in having some generic utility which will map versions (in either
>>> format) to database columns? If so, which version format would you
>>> prefer?
>>>
>>> We are on a tight schedule here, as we want to begin landing
>>> artifact-related code soon. So, I would appreciate your feedback
>>> during this week: here in the ML or in the comments to [3] review.
>>
>> Because you should have more things to look at:
>>
>> http://docs.openstack.org/developer/pbr/semver.html
>>
>> We've already done some work to try to reconcile the world of semver
>> with the world of PEP440 over in PBR land.
>>
>> 
>>_________________________________________________________________________
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

So Semantic Versioning, as I’ve already mentioned in the past, isn’t
really a de facto standard in any language community but it is a language
agnostic proposal. That said, just because it’s language agnostic does not
mean it won’t conflict with other language’s versioning semantics. Since
we’re effectively reinventing an existing open source solution here, I
think we should look to how Artifactory [1] handles this.

I haven’t used artifactory very much but a cursory look makes it apparent
that it is strongly decoupling the logic of version management with
artifact management (which this set of changes isn’t doing in Glance).

The primary argument (as I understand it) for using SemVer with Artifacts
in glance is to have a way to automatically have the service create the
version number for the uploader. Artifactory (and it’s “Pro” version) seen
to leave that to the build tooling. In other words, it is purely storage.
It seems to sort versions alphabetically (which everyone can agree is not
only suboptimal but wrong) but it also provides the user a way to alter
how it performs sorting.

Is there a reason (beyond not being an OpenStack project) that Artifactory
isn’t being considered by those pushing for Artifacts to provide a CD
service? Judging by the support it seems to roughly have for other
services (via a “Pro” version) it would appear to be able to suit any this
need well with little work by the deployer who needs to serve more than
one use case.

[1] http://www.jfrog.com/open-source/#os-arti