Add more simple draft and publish versioning mode

[LasseRosenow]

Summary

With versioning stabilized, I think it is time to discuss possible improvements to make it more accessible for more basic use-cases that only need simple draft and publish architectures.

The design with multiple branches certainly has many good use cases, but I think more simple use cases should also not be forgotten. That is why I propose not to change the current implementation and make it less complex, but rather to add additional configuration options to it.

• Our requirement would be to just have 2 branches. One called published and one called draft for example.
• If you open an item, you would usually be in the draft branch, so changes that you make are not automatically published.
• It would be good to just have a very obvious publish button next to the save button for example.

Basic Example

No response

Motivation

I think this workflow would be very good for our users to prevent them to accidentally make changes, that should not be published etc. but it would also be very transparent and easy to understand for them, that this change is not yet published, because there is a large publish button next to the save button.

My main concern with the current design is, that it is too complex for many users and would end up not being used by them.

Detailed Design

Proposed Solution

• Add a very obvious publish button on branches that are not main. (Next to the save button?)
• Add the ability to configure the default branch that is selected for a collection.
• (optional) disable the ability for every user (including admin) to create or delete branches => To prevent accidentally destroying the 2 branch configuration outside of the data model settings page
• (optional) make this configurable via ENV variables, This way all my collections in all my projects could automatically have a draft default branch and I could always rely on this workflow without needing to configure it for every collection every time :)

=> This way I could create a draft branch for all my collections and set it as the default branch. Now every user would just edit the draft branch and click the publish button to publish the changes.

Requirements List

Must Have:

• configure default branch of a collection
• limit maximum branches count to 2
• prevent branch deletion for everyone

Should Have:

• hide branch toggle selector (only draft should be shown)
• add a publish button next to the `save´ button

Could Have:

• Change the versioning toggle in the collection settings to a select menu that has the following items:
  • Basic (draft => publish)
  • Complex (multiple versions => promote)

Drawbacks

Now it would be necessary to maintain 2 versioning systems.
That is why I think it is necessary to design this new feature around the existing system, by only adding some small constraints here and there.

Alternatives

Adoption Strategy

Adoption is just like the current versioning system:
Users can enable it for each collection by selecting the Basic mode in the new versioning select menu.

Unresolved Questions

No response

[rijkvanzanten]

Big fan!

[wilfredo-lorca]

Hi @LasseRosenow

Thanks for this new approach that I also think can be a more complete solution, also threating content like git branches. But I want to recall a behavior that might be addressed with the current design perhaps. I will put this example:

I have the default Main version. From this I make a new version called backup. Next I created a second version based on the Main one and call that second one draft version. Next step I update some changes in the draft version and save after that I Promote the draft version to Main. The problem is that when I promote the version. My backup version have the changes that I promote to the Main version.

For our use case will be more positive that the backup version have the first version that we had before the change and we can in the future go back to that past changes.

My question is. Am I wrong or this approach It's not the one that was target in the beginning?

[formfcw]

* Add a very obvious `publish` button on branches that are not `main`. (Next to the `save` button?)

I really love this idea and I think we could take this feature a step further and completely replace the Save button with a Publish button. The reason for this is that we could now easily implement auto-save, because every time we update the item the changes that we have made will be stored in the latest version of the draft branch. This means we can't accidentally overwrite a published version.

This clears the way for …

AUTO-SAVE!

[rijkvanzanten]

🙏🏻🙏🏻🙏🏻 To me "auto-save" is effectively overwriting whatever is your current latest draft version entry 🙂 (rather than making a new 'commit' very every auto save)

[formfcw]

I totally agree

[formfcw]

… and auto-save would also lead to live preview.