Hi Client, Thanks for your input.
We actually support the scenarios you speak about, yet in a slightly different way. The authors of the Artifact Type (the plugin developers) may define their own custom field (or set of fields) to store their "sequence" information or any other type-specific version-related metadata. So, they may use generic version field (which is defined in the base artifact type) to store their numeric version - and use their type-specific field for local client-side processing. -- Regards, Alexander Tivelkov On Tue, Feb 10, 2015 at 11:37 PM, Clint Byrum <cl...@fewbar.com> wrote: > Excerpts from Alexander Tivelkov's message of 2015-02-10 07:28:55 -0800: >> 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. >> > > Hi. This is really interesting work and I'm glad Glance is growing into > an artifact catalog as I think it will assist cloud users and UI > development at the same time. > > It seems to me that there are really only two reasons to care about the > content of the versions: sorting, and filtering. You want to make sure > if people upload artifacts named "myapp" like this: > > myapp:1.0 myapp:2.0 myapp:1.1 > > That when they say "show me the newest myapp" they get 2.0, not 1.1. > > And if they say "show me the newest myapp in the 1.x series" they get 1.1. > > I am a little worried this is not something that can or should be made > generic in a micro service. > > Here's a thought: You could just have the version, series, and sequence, > and let users manage the sequencing themselves on the client side. This > way if users want to use the _extremely_ difficult to program for Debian > packaging version, you don't have to figure out how to make 1.0~special > less than 1.0 and more than 0.9. > > To start with, you can have a default strategy of a single series, and > max(sequence)+1000 if unspecified. Then teach the clients the various > semvers/pep440's/etc. etc. and let them choose their own sequencing and > series strategy. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
