Track "live workflow version" instead of disallowing edits while project is live

[marten]

What happens currently is that people just unlive their project, make edits, and relive. All it really does is prevent accidental edits to the workflow. But since liveness and publicness are two concepts, people will still be doing work while a project is not live.

A better solution is that Workflows track their "live version" (as defined by Papertrail). That's then the version the public API returns, but in the project builder you always see the latest version, and are free to make changes constantly. Whenever a workflow is in a neat state again, the project builder should have a "deploy" button to make the latest version the live one.

We'll probably need to add a version parameter to the workflows so that you the PB can request "latest" while without a version it returns the deployed one.

Other additions might be to allow owners to preview the latest in the classify page, and to allow owners to revert the live version to a previous version in case of problems with the latest one.

[mschwamb]

@marten - Something you might not have considered, though maybe you have. I found once you launch a project publicly you're really done for a long while. The only time I'm unliving right now is to switch datasets or editing something in the help (since I link to other pages in the help when url redirects have changed I had to make edits).

If making a subject set live on the site was taken out of the locked workflow editor I think there would be less need to edit a workflow once a project is 'live'.

[vrooje]

I think this is a great idea and is much cleaner than switching back and forth between live/not-live several times. It would allow people to refine changes they need to make and preview them without making them live, then switch smoothly to the updated workflow without have to deal later with classifications made while the project was public but not live (and which may or may not need to be thrown away). That could make for better aggregation too, without loss of useful classifications or inclusion of not-useful classifications.

[camallen]

Yeah i really like this too!

[alexbfree]

+1 for this!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[camallen]

we need to make this happen, how we do this without paying the cost to reify old data in a serializer call i'm not sure (caching?) see #2512 for a newer use case.