Changeset-based versioning model

It's frequently the case that you'll want to work on an entire set of changes that all need to be tested, previewed and approved ahead of being published on a specified target date. For that reason, in designing Cloud CMS, we opted to go for a  changeset-based versioning model (as opposed to merely document versioning). Bulk modifications can be stored on each changeset and entire branches of changes can be worked on ahead of a merge back to the master branch.

Cloud CMS has this model of versioning down in its core. This lets you carve off new branches whenever you want and merge them at any time. And, you can set up different security and access rights to branches. In that sense, you can sort of think of a branch as a private team-based workspace. It can also be a shared workspace if you open it up to the organization...

This kind of versioning model is really useful for web and mobile sites, for example, where you have lots of changes to things like articles, news items and possibly JS, CSS, HTML and whole sets of other little files. It also applies to complex node structures where you have an object graph and lots of parts of the graph being updated for a release. For example, a book with chapters and chapters with pages. Finally, another common use case, is I18N translation authoring (localized content is simply another node in the graph, linked to a master base-localized node).

And, of course, this is all available thru  our REST API