Add tooling to up/down/side-grade CMS versions

[mwpowellhtx]

Is your feature request related to a problem? Please describe.

I understand some sort of versioning capability exists; though at the moment not sure precisely what that is, getting my feet under me. Something to do with ContentItemVersionId, but what does this mean exactly. Are we able to attach a serialized System.Version, for instance, or an enhanced SemVer, let's say.

Describe the solution you'd like

Falling out of my discussion concerning CMS in general, OrchardCore in particular, disposition towards source code, I leave with the impression there is a possible tooling gap around different scenarios, whether to up/down/side grade to whatever version served from the database.

Describe alternatives you've considered

Open to suggestions. If there is backend API supporting this, or just what the terrain and/or roadmap looks like accomplishing this goal.

[Skrypt]

Every time you publish a ContentItem it creates a new record in the ContentItemIndex and Document tables. These 2 tables are using a map/reduce data pattern. So, in the Document table, you have the reduced data as JSON in the Content column and we are mapping some parts of this data in the ContentItemIndex. So, if you look in the ContentItemIndex table you will see 2 columns, one is ContentItemId and the other ContentItemVersionId. So, each time that you save a content item as a draft or as a published ContentItem it will create a new record with a ContentItemVersionId. As for the Document table, there is a Version column there that I believe is a technical field for YesSQL.

As for extensibility, I think everything is possible. You could easily use a SemVer versioning system on your ContentItems if needed but that would need some thinking first on how to implement this. Actually, I'm guessing that you would like to know from which version of a module some ContentItems have been created with. Actually, we don't store this data but that could maybe be useful. Although, we create data migrations that go with modules updates. You can look at migration.cs file in an Orchard Core module to see how it is automated. We store the module's version in the Document table in a specific row. So, we assume that the data has been migrated for the proper module's version installed.

[mwpowellhtx]

Actually, I'm guessing that you would like to know from which version of a module some ContentItems have been created with. Actually, we don't store this data but that could maybe be useful.

You read my mind there; yes, the natural question is to have traceability which assembly(ies)/versions were involved during authoring. At minimum a top level entry assembly is probably best, assuming we have appropriate project and/or package dependencies, which we should. But yes, that seems the natural question when outlining a backup/recovery plan.

[Skrypt]

The idea seems like a good one. Let's see what @sebastienros thinks about it.

I believe that we already store the Assembly Type Name. Though, a OrchardCore.ContentManagement.ContentItem for example is an abstract type that can change over time dynamically because it is composed in the Admin UI (runtime). I believe that we talked about the fact that we wanted to have the ability to create Content Types that cannot be changed from runtime at some point. Meaning that a module could define "static" content types from code and that these could be versionable in the context you are suggesting.

[mwpowellhtx]

Yep, exactly; there might be some sane floor/ceiling that can be supported depending upon the known assembly versions in the picture. Seems like a perfectly sensible thing to do.