As indicated under #13387 - the version should be treated as a first class citizen in redmine.

Currently, there is a great work-flow model available for Issues. For versions they are open, locked and closed state. However, this model should evolve to allow multiple things:

Allow for user defined status of versions (like in issues). This can be defined as per development process. This will also allow to add stages such as 'Approval' Q&A, field-trails, user-acceptance. etc. which currently are not present.¶

There can be workflow setup for versions where in issues of certain tracker can be allowed to be added or not depending on the status. For example. after the build-complete stages - bugs can be added but features can't be.¶

There can be also provision to make custom fields appearance and make it appear/read-only/compulsory etc. Currently there is no such provision.¶

The issues can be moved to specific status based on version status. For example, by moving the version from development to QA - it will move all issues under the version to corresponding versions.¶

The reverse should also be linked: unless issue satisfy all requirements to change status from x to y it should not allow the version status to change. For example, unless root-cause or testing specific details are filled, issue shouldn't be allowed to move to resolve, that should also prevent the corresponding version to move to complete/close status. This will have critical reinforcements of processes.¶

Finally, like issues, version status should be allowed to change from specific states to other states only by specific roles. This will reflect huge possibility for software development processes. For example, only QA related people can be allowed to move version from Testing phase to ready phase. only specific people can move version from the scope-freeze to development.¶

Customizable state work-flow model will allow many software development processes mapped exactly how it is followed in the actual processes.