Open Stack

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