Hi Ian, On Tue, Feb 10, 2015 at 11:17 PM, Ian Cordasco <ian.corda...@rackspace.com> wrote: > I think the fundamental disconnect is that not every column in a database > needs offer sorting to the user. Imposing that restriction here causes a > cascade of further restrictions that will fundamentally cause this to be > unusable by a large number of people.
I didn't say that every column needs to offer sorting. However, ability to differentiate between different artifacts and different versions of the same artifact, as well as ability to sort and filter these different versions according to some criteria is one of the core features we were looking for when designing the whole artifact proposal. In fact, the initial request for this feature was not even made by me: I was asked about versions at the first design summit where we initially suggested artifacts (Icehouse mid-cycle) and in subsequent email and IRC discussions. The first design proposal which was presented in Atlanta already included this concept and so it was approved there, so this feature was always considered as a natural and important concept. I don't understand why it causes so much confusion now, when the implementation is almost complete. > Except for the fact that versions do typically mean more than the values > SemVer attaches to them. SemVer is further incompatible with any > versioning scheme using epochs and is so relatively recent compared to > versioning practices as a whole that I don’t see how we can justify > restricting what should be a very generic system to something so specific > to recent history and favored almost entirely by *developers*. I believe any person in software industry may invent their own versioning scheme - and most of them will be incompatible with each other. If you attempt to build something which is compatible with all of them at once, you will eventually end up having plain strings, without any semantic and precedence rules. This definitely does not satisfy our initial goal (see above). Instead, I suggest to choose the scheme which is strict, unambiguous and satisfies our initial goal, but has maximum possible adoption among the developers, so most of the adopters will be able to use it. Semver seems to be the best candidate here, but any other proposals are welcome as well. Meanwhile this does not prevent adopters from having their own schemas if they want it: Artifact Type developers may add their own type-specific string metadata field, put some regexp of code-based constraints on it - and use it to store their own "version". Yet they will not be able to utilize the version-related features which are built-in into the Glance. > Because up until now the only use case you’ve been referencing is CD > software. There is some disconnect here: I believe the message which started this thread was the first time where I mentioned Artifact Repository in the context of Continuous Delivery solutions; and I was saying about CD system built on top of it, not about the Artifact Repostiory being a CD-system on its own. All other use-cases and scenarios did not mention CDs at all: Artifact Repostiory is definitely a generic catalog, not a CD solution. -- Regards, Alexander Tivelkov __________________________________________________________________________ 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