@ibgrav Thanks for the insights. What you are mentionning is going to be a “versionning / history” like feature not included inside the current draft & publish scope.
Right now this will be as you said a basic published_at flag. This is a first step towards better publication workflows in the future but we didn’t want to develop a big feature without getting more feddback on the basic usage first 
@VMonsch We did discuss it yes 
I will get into more details so you may understand the bigger picture a bit more. there are multiple points I want to touch on.
First of all, strapi is both a framework and a CMS.
-
The framework actually doesn’t know what publication is (meaning the REST API doesn’t either) It just has a published_at field that is set and that is auto filtered to be different than null.
This means we can enable live/draft status with the REST API by allowing user to set this field (not possible in the beta). This will allow you to do whatever you want using the API and you are free to implement it like you want. -
On the CMS side of things, strapi works with a Content Management API (coming from the content-manager-plugin) This API does expose the CMS features and you can totally use them if you want. The plan is to make them more robust and document them in the future to respond to more advanced usecases. But there are already usable. you will need an Admin user token to use it as it requires logged in user to work.
We will certainly continue to differentiate even more both the REST API and the Content Management API to keep strapi usable as a simple API Builder that doesn’t expose features that work in a CMS and require users / permissions and such.
I hope this helps you understand a bit more the strategy
We will be releasing the stable directly as we only got a few bugs to fix and we won’t be changing the feature scope for now.