Versioning idea

Yep. I have the impression that Jason is addressing here far more things than plain "versioning" (that’s why I coined "back up"). As far as I understand it (not all too far, to be honest ) the content/baseline concept also solves the multilingual-requirements and other contextual (or "cultural") issues. This is more creating "variations" than "versions" in that they exist and are used in parallel, depending on the context. But, obviously, each version can also be seen as a variation, and the "versioning" in the narrower sense is also just a "context" - so versioning in any sense would be doable. I guess what Gregg has in mind as well as Mark, was just a place to keep versions of documents (in the modx environment this must include external parts of content like TVs and chunks), for backup and approval needs, mainly, maybe multilanguage too. And I guess it would make sense to implement that in 0. branch, whereas the "baseline" concept seems to be more the general 1. solution.

Quote from: romdg at Aug 15, 2006, 10:27 AM

Hey Jason,
Thanks for weighing in on versioning, as the approach you suggests most definitely looks promising. I think I was unclear in what versions I was talking about. From a subversion/cvs standpoint your statements are 100% right on. But I was referring to the actual content in the CMS. The (templates, TV’s, chunks, snippets, plugins, etc) build a structure for our data, but I am interested in maintaining versions of the content itself as seen on 37 Signals Writeboard. As the *content* tables house the actual document the themplates, snippets, and plugins provide tools to format, arrange, and display the data. I am conjuring up a solution to provide copy versions and in turn a approval mechanism on what is published to the live site. Chunks house flat data and would benefit from content version control as well. Sorry if I was unclear, but you are absolutely right that there is a need to define version control in the tool itself.

Cheers,
Gregg

I am not talking about CVS or Subversion, though the implementation is certainly based on some concepts from these tools; I am talking about the content in the CMS. And this structure will be able to allow creating of writeboard-like functionality, wiki-like versioning features for any content, custom translation management, and even custom publishing workflow. Draft revisions would be part of this approval mechanism, and rolling back content to any version would be possible. It would even be possible, with some management interface work, to merge various revision points together.

I think what makes this confusing is that in this future architecture I am describing, there is no content stored in the site_content table any longer. And the default [*content*] becomes just another TV-like element with the name ’content’. So, in a sense, a document in MODx is really no less than the sum of it’s parts, not just a single [*content*] item stuck in a template, so, in my perspective, you manage the content where it actually exists, in the components that produce it. This increases the freedom of expression you have when working with the default content of a document, as well as promotes content re-use throughout the framework.

Hey Jason,
Thanks again. As I am unfamiliar with the new architecture I was stuck on old structures(and old table columns) in trying to map out a solution. I am very excited by the direction you mentioned in your last post and wondering what the timeline is for that form of architecture to be implemented, not the versioning itself but the the architecture that supports it.
Cheers,
Gregg

so, in my perspective, you manage the content where it actually exists, in the components that produce it.

So we will finally get rid of the ancient concept (more a "metaphor" meanwhile) of content being bound to or rooted in a "document".
And switch to a new concept which fits much better to what we’re doing already: managing databases, dynamic components and processes. Great vision! Thanks Jason, for these insights and good luck!

Quote from: romdg at Aug 15, 2006, 10:55 AM

Thanks again. As I am unfamiliar with the new architecture I was stuck on old structures(and old table columns) in trying to map out a solution. I am very excited by the direction you mentioned in your last post and wondering what the timeline is for that form of architecture to be implemented, not the versioning itself but the the architecture that supports it.
Cheers,
Gregg

Understood Gregg, and by no means am I trying to discourage you from attempting a solution on the existing code base; just trying to keep people informed of the current efforts being undertaken by the core team.

As for timelines, I do not have any accurate estimates yet, but I do have the new core prototype running with about 70% of the planned features, including the revisioning, which I implemented the majority of last night. The only real major work left to do is build the new manager interfaces with the core code, write the migration guides, work out installation and upgrade logic, and then start working on the optimized code for PostgreSQL and SQLite ports.

I will hopefully be able to release a full 1.0 roadmap and some kind of timeline for release as soon as we have 0.9.5 ready to deliver, if not sooner. And there are also plans for an early access program for those interested in contributing to the efforts in various ways.

sweet... Will keep my eye on the ’0.95 logo’, If only I had a new mac running leopard I could build a widget...
Cheers.

Quote from: OpenGeek at Aug 15, 2006, 11:51 AM

I will hopefully be able to release a full 1.0 roadmap and some kind of timeline for release as soon as we have 0.9.5 ready to deliver, if not sooner.

Mmm, there are currently two features I’m working on:
1. create "automatic document groups" for each (manager-)user
2. create an option to save the previous version of a page (using a clone of site_content and tv_content tables)

If those features are part of the 0.9.5 release, I’ll stop. If not, I’ll continue.

I really hate do waste my time on doing things others are already doing and doing better - since I’m not a "pro-coder" - and with a much tighter/better integration to MODx.

Waiting for your recommendation.

They’re not part of the planned 0.9.5 release (and it’s pretty much in feature freeze).

OK, thanks Ryan, I’ll keep on going!
Do you have a list of the "frozen features", I mean those which will come?
I know: you’ve probably been asked that a hundred times before ...