Short answer: Using the API, no. 

Long answer: Yes, but you will need to create a custom query directly from the database. 

What is the requirement/reasoning behind the question?

Well... the reason behind this is that we have more than one build of our solution that contains k2 processes.

while the QA is testing the old build; the dev team is working on the new build.

we want to maintain the processes as they were for the old build. and we want the dev team to work on the new version of k2 processes of the new build.

i hope this is enough 

First off, you will need to create a custom Worklist for this. The default Worklist does not cater for this

Easiest way I can think of is to retrieve the user's Worklist for all versions and then do a filter directly to the DB using the ProcIntsID to get the Proc ID from the _ProcInst table and then the Version from the _Proc table.

I would NOT recommend this for Production as performance is likely to be poor under load. 

I guess no need for this; as you need to leverage K2 feature of having two environments or more of the same server --> "Development" and "Production" or "QA" but you shall find them as the following:

VIEWING K2 ENVIRONMENTS (http://help.k2.com/en/EnvironmentLibrary_Whitepaper.aspx#)

Existing environment definitions can be easily viewed in Workspace. Follow these steps to list the Environments:

1. Click on Management | Management Console

2. Expand the K2 server node

3. Expand Environment Library

4. Expand Templates

5. Expand Default Template

6. Select Environments

By default, K2 creates both a Development and a Production environment definition, which you can view in Workspace, as shown in Figure 14. At the time of creation, these two default environments contain identical values for all environment fields.

I don't recall how to leverage them sorry...  

thanks for your answers

after deep thinking... this is what i did :

1. rename each visual studio solution to a name that reflects the status of the solution . I.e QABuild or DEVBiuld.

2. Compile and deploy both solutions: this will result in the addition of new processes under the Processes node in the workspace: these processes will have the same name but will lie under siblings having a different name. - the same processe will have a copt of itself under a different build- so the process will be the cousin of itself.

3. any modifications done under some VS solution on some process will not affect other process under adifferent solution.

4. in case the Worklist needs to be filtered we can filter the folder proerty in the criteria provided to the worklist.

if you have any other suggestions or corrections please dont hesitate to share with me.

many thanks for your participation