On 02/10/2015 12:15 PM, Ian Cordasco wrote:
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  handles this.
"Reinventing an existing open source solution" is a bit off-the-mark IMO. Artifactory is more of a SaaS solution through bintray.com -- paying some lip-service to open source more than anything else.
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).
Alex's spec is merely proposing to standardize on a single way of managing versioning. It isn't coupling artifact *management* with anything whatsoever. In fact, the idea of Glance being an artifact repository has nothing to do with the management of said artifacts -- which things like Heat, Murano or Solum handle in different ways.
The idea behind the Glance artifact repository was to store a discoverable *schema* for various objects, along with the object metadata itself. I can see Nova and Cinder flavors, Glance, Docker or AppC image metadata, Cinder snapshot and differential metadata, Murano application manifests, Heat templates, and Solum deployment components all being described (schemas) and stored in the Glance artifact repository.
What I have not heard from anyone is the idea to marry the management of the things that this artifact metadata with Glance itself.
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.
I don't know where you get the idea that a service (Glance, you mean?) would automatically create the version number for some artifact. The spec talks only about the ability of the artifact registry to sort a set of artifacts by incrementing version number, and do so in a reasonably short time frame -- i.e. have a database column indexed for that purpose.
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?
Because we're not looking to create a CD service? :) AFAIK, the artifact repository is a generic storage system for schemas and metadata, nothing more.
Best, -jay > 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.  http://www.jfrog.com/open-source/#os-arti __________________________________________________________________________ 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