Maarten, coming back to this really old thread (over two years old)…
We have now been using Clausebase for a while and I’ve been trying of late to be a little more hands-on, so that I can be more conversant on coding and helpful to Elmer.
I was tweaking a clause and was excited to “rediscover” versioning. However, I soon “rediscovered” that versioning doesn’t work the way we thought it did or the way we think it should. I soon found this thread, and said “Oh, yeah, now I remember.”
Having reread your thread, though, after two years and with significantly more Clausebase experience under our belts, we (I’m going to speak for Elmer here) still don’t understand your issue with setting it up the way we are suggesting.
To recap, here’s the way we think it would be very helpful for versioning to work:
- We have existing clause C1.
- We wish to make changes to that clause without those changes being live in any document yet. So we click to create a new version, C2, and make edits there. (And ideally, we can preview/simulate what C2 would look like.)
- When we are ready for C2 to be live, we click somewhere to “submit” or “approve” C2. (Isn’t this called a “commit” or something like that in software parlance?)
- Upon submission, all versions of C1 are replaced with C2.
- C1 is still saved somewhere where it is searchable (e.g., tagged as a “previous version” or something of the sort).
- An added bonus would be the ability to “roll back” to C1, e.g., if we find an error in C2 or we decide we simply like C1 better. Clausebase would just do the above, but in reverse.
Our suggested way of handling versioning gives authors the ability to:
- Work on clauses without risk of inadvertently messing up current clauses/documents.
- Update all clauses at once, across documents (as you noted, this is the central feature of Clausebase).
- Save, search, and revert to old versions.
If you’re not going to do versioning like this, I don’t see what the point is of having it. In its current form, I view it as unusable. (Elmer could not even find a prior version using search or browse, though I imagine it’s got to be findable somehow.)
Right now, when we want to improve a clause, we have two sub-par choices:
- Work in the current clause. This will make all final changes visible instantly upon submission, but allows no saving of work in progress or any easy way to preserve the old work.
- Create an entirely new clause (not a new version). This allows us the opportunity to save work in progress, but when the new clause is done, one would then have to manually substitute the new clause for the old one in every single template, which is too much work.
In short, we want to preserve the central editing approach of Clausebase, i.e., that all changes to a clause go live everywhere the clause is used, but we also want have an easy, safe process for updates and improvements. The current versioning implementation doesn’t seem to accomplish anything, unless we are misunderstanding.