Open Stack

Hi Ian,

On Tue, Feb 10, 2015 at 11:17 PM, Ian Cordasco
<ian.cordasco at 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