K2 Process Versioning

Hi Jarrostick,

Whilst at first glance seems crazy behaviour, is actually very sensible. The versioning of your workflows ensures that any unfinished workflows that started before you modified it can still be completed (as the old version). The versioning process also means you can swich the current version of your workflow in the workspace, so if you are piloting a new version and it has a fault, you can log into the workspace and restore the old workflow (the previous version) as the version that should be running. This is very useful out of the box functionality that our customers really like.

As for having 60 versions... if you have 60 versions on your production server, this is not good practice... all development versions should be created on virtual machine development machines or staging servers, this ensures that your production server only has fixed releases of your workflows, i.e. maximum of 10 versions if your development lifecycle was 12 months or something like that.

My development team have developed over 100 versions of our workflows, but this doesnt affect the production server as we have only delivered workflows to our customer twice, so there are only two fixed releases of the workflow on our production server.

If you don't have the luxury of development, staging and production servers, i'd recommend your team do their development on virtual machines, this will reduce risk and keep your production server streamlined.

I'm sure however, that someone has come up with a way of removing old version on a K2 server through a SQL script - perhaps in the short term this is what you are after?

hope this helps

Martin

Hi Martin,

I read your reply and basically i understand the concept and usage of versions within K2, however my point was more related to the possibility or not to switch off this versioning feature of K2.

I'm not talking about production, when i mentioned the 60 plus versions is in our development environment. Of course this is also related to the approach we take to the processes design whether we make more or less deploys, but anyhow i think that in earlier stages of a process development there is no need to store versions this way. This surely makes the deploy take longer and consume more space in K2 database.

Do we have to live with this K2 versioning stuff or can we switch on and off at our will.

Thanks