Drop v3alpha1 schemas from the spec and rely on v2 only

[jensh007]

It does not make sense to have a specification with two different schemas. Drop v3alpha1 and put this to a separate document outside of the scope of the spec. Same for normalization format v1 and other legacy type.

[morri-son]

Hi @jensh007 and @mandelsoft, I also stumbled upon https://ocm.software/docs/component-descriptors/version-2/ which mentions "legacy". Is v3 really replacement for the v2 or isn't it just another, Kubernetes resource like - format used for the same? I know that for example the colleagues from landscaper did not switch to v2 as there is no additional functionality, but a lot to do to adopt the v3. If this understanding is correct, we should think about how to explain this better and also not call v2 "legacy". If we really want to promote and prefer (only) v3, then we should make it the default and deprecate the older versions and delete them after they've become deprecated. What do you think?

[vasu1124]

I don't think that v2 is "legacy". Afaik, there are no new semantics between v2 and v3. We are using the "version" moniker as serializing/deserializing format.
@mandelsoft listed the arguments why "version" is appropriate. But as end user, it still confuses.

[jensh007]

We need to come out with one version. Nobody will understand supporting two different schemas. Personally I do not see value in v3 pretending to be a Kubernetes resource which is not one. Looks to me more confusing than being helpful. We should agree on one, drop the other entirely from the public spec. If used somewhere internally and needs to be maintained keep it in code but not in the spec. This would be my preference.

[hilmarf]

and once it's done, we should publish it e.g.: https://github.com/SchemaStore/schemastore/blob/master/CONTRIBUTING.md#how-to-add-a-json-schema-thats-self-hostedremoteexternal

[morri-son]

adding @hilmarf

Personally I like the v3 more as I'm used to the KRM, but I think that many cases people, also from the K8s ecosystem, deal with data stored in schemas totally different from K8s resources. So, I don't think that anybody really minds about OCM has the v2 or v3 as a format when it is about deciding for OCM. I get the point of having two "versions" in parallel, just describing different (de-)serialization formats, but an end user tends to relates different versions to something different, mainly something "newer", "more mature", "with more functionality".

I created open-component-model/ocm-website#182 (@mandelsoft , @jensh007, @vasu1124 please check, review and merge) to at least try to explain the current situation a bit better. But this is just a temporary workaround and we should decide for keeping one or multiple soon and if we go for multiple, we should also explain this as part of the spec and the ocm website.

[achimweigel]

Please keep in mind, the efforts in other projects if we remove v2.

[morri-son]

related to #262