Multiple open projects and how to handle them

Related products: Software Factory Windows GUI Universal GUI

In the SF it is possible to open multiple projects or project versions. For example you can open functionality for version 1.00 and version 1.10 of your branch. However you are able to edit both. Sometimes if you need to check something with older versions/different branches this can become very confusing and there is the risk of editing the wrong branch or project.

Multiple ideas:
 

  1. Do not switch the active project upon switching tabs
  2. Add some kind of colour (red) or a warning sign (red exclamation mark) to show the current tab is not part of the active project
  3. Make any tab that is not the active project read-only.
  4. Make it possible to switch all opened tabs to the latest version, with the click of a button
In version 2018.3 we added a warning message when selecting a non-development version or switching to an open document for a non-development version. Hopefully this already helps to prevent you from accidentally working in an older version.




I wouldn't mind having inactive (or better, any status other than development) versions of a project or branch made completely read-only. i have stepped in that pitfall before in the past, making several changes in templates, thinking I was working in a development version... A restore of the SF was the quickest fix that time.



If one really needs to make changes to non development versions, changing the status of such version to development is always an option.
I think that editing versions that are not 'in-development' should be prevented at all times. There is usualy no reason a developer should want to change past versions. The only situation I can think of is applying a hotfix to an older version or something. But this is the exception, not the rule. If you want to do that, you can easily change the status of the old version to 'in-development' for a few minutes and then apply the change.
I think that editing versions that are not 'in-development' should be prevented at all times. There is usualy no reason a developer should want to change past versions. The only situation I can think of is applying a hotfix to an older version or something. But this is the exception, not the rule. If you want to do that, you can easily change the status of the old version to 'in-development' for a few minutes and then apply the change.



I strongly agree with Robert Jan.

Instead of making your version go red (sometimes it will, sometimes it wont) or giving a message, I rather not be able to change anything in project versions other than "In development"; but I could agree if some other statusses should not become read-only, but those should be reviewed.



Editing something in a previous, inactive, version is such a waste of time, and sadly it sometimes happens. 😑
This helps when checking something with an older version of the project/branch. This does however still leave the risk of changing something in the trunk, a different project or a different (active) branch.
Actually, the problem with the pop-up right now (telling you the selected version is not in development) is that it comes right at the moment when you make a deliberate decision to switch to another version. When you switch to another tab which automatically gets switched to another version (or whatever), the pop-up does not come up and you are still unaware you are in an inactive version
It seems that there is a lot of agreement on ONLY being able to change project versions that are in development.



I'd like to improve this suggestion further; when copying a project version, it should automatically change the status of the previous one to inactive, so that, from that point onwards, the old project version cannot be changed anymore.

Alternatively, you could ask the user for a new status of the old (to-be-copied) project version.
It seems that there is a lot of agreement on ONLY being able to change project versions that are in development.



I'd like to improve this suggestion further; when copying a project version, it should automatically change the status of the previous one to inactive, so that, from that point onwards, the old project version cannot be changed anymore.

Alternatively, you could ask the user for a new status of the old (to-be-copied) project version.




One of the things i often do is change the default of the copy project vrs task. Make sure it goes + 0.01, instead of 0.10. Then I edit the task itself, to set the previous version to inactive.



I'd say just add a BIT with: "Set old version inactive" default value = 1



code:
update project_vrs
set status = 3
where project_id = @from_project_id
and project_vrs_id = @from_project_vrs_id
and @from_project_vrs_inactive = 1




Actually, the problem with the pop-up right now (telling you the selected version is not in development) is that it comes right at the moment when you make a deliberate decision to switch to another version. When you switch to another tab which automatically gets switched to another version (or whatever), the pop-up does not come up and you are still unaware you are in an inactive version



This is exactly why I strongly agree on RJ's idea on preventing any changes to inactive versions. I have asked for this before (like 2 years ago) and until now there still isn't a good solution. The red project version isn't working well and is not enough, nor is the message Jasper wrote about, as you noted in your reply Pim.
I did it again. Including an IAM synchronization. 😞
The following idea has been merged into this idea:

All the votes have been transferred into this idea.

For hotfixes a hotfix-status could be an extra option.

Further completely agree that changing past versions is not something you should want.

PS Other version control systems only store changes in a new version, whereas in Thinkwise you first create a new version and store changes in this new version, until the moment comes for creating a new project version. Switching from other version control systems to Thinkwise took some time in getting used to this.


The following idea has been merged into this idea:

All the votes have been transferred into this idea.

The following idea has been merged into this idea:

All the votes have been transferred into this idea.

The following idea has been merged into this idea:

All the votes have been transferred into this idea.

I think this idea has grown a beard…


We are training a bunch of new people who joined our project, and as a Product Owner I decided to participate in building a Project case from scratch. You won’t believe how many times my colleagues and me have been falling in this trap! It results in frustration with my developers as well as overall productivity loss.
 

And this is only one of the quirks of the Software Factory that cause the platform to be too difficult to learn without experienced people by your side. The SF is not exactly supporting the whole Thinkwise platform strategy this way…

 

@Jeroen van den Belt @Jasper Unbelievable and utterly disappointing that this Idea is open for almost 3 years without proper resolution! When can we expect a proper solution?


Hi @Arie V,

We fully understand that you would like to see this idea implemented. We can assure you that we take this wish very seriously, it is high on our backlog for this reason. The status of the idea did not reflect this, so I updated it to ‘On the backlog’.

In fact, we have recently started investigating a working method in which this situation will no longer occur. It's a little bit early to share any results yet, or to set the status to ‘Active’ since we haven’t started implementation. As soon as we have relevant (status) updates to share, we will of course share them in this topic.


In fact, we have recently started investigating a working method in which this situation will no longer occur.

@Jeroen van den Belt I've read about the versioning/branching concept change you're considering in the Release Plan 2022.2, which states nothing more promising but ‘During 2022 we will be exploring different options to improve this...’. That sounds as if at least another year will go by before we see the implementation of the new concept.

In the meantime a fix is still very valuable. How hard can it be to simply set all screens to ‘Read Only’ for an Inactive Project Version? Would assume that isn't too hard with something like a Layout and Context procedure that is dynamically assigned and generated for all Subjects?


Hello everyone following this topic,

Since we have recently released the 2022.2 version of the Software Factory, we have already started working on the new features for the 2023.1 release. One of these features is handling versioning in the Software Factory through temporal versioning.

This means that we will do a complete revision of how projects and project versions are managed in the Software Factory, which also includes many of the issues discussed in all the comments above.

A sneak preview on what we are planning on implementing can be found in the following blog:

Once we are further along with the development we will present you with another blog with further details on the specific changes that will be noticeable by developers that use the Software Factory, so stay tuned 😄

Hopefully this will bring some enthusiasm for the future!

 

@Arie V , @Robert Jan de Nie , @Erwin Ekkel : I tagged you guys since you guys seem actively involved in this topic 😅


On the backlog→Next release

Next release→Completed