Migration task for Requirement Yogi 3.0
In Requirement Yogi 3.0, we have changed the data model. The new data model:
- Supports external properties,
- Supports better management of dependencies and versioning,
- Ensures no customer will reach the maximum of database IDs (It's a technical limitation, don't worry, it's solved),
The migration task will deactivate the app during the migration, and it should take in average 1 minute per 1000 requirements. See Migration to RY 3.0: FAQ for more information.
Estimates!
This is the main visible feature for version 3.0.
-- TODO
Visual changes for the dependencies
- We don't call dependencies "TO" and "FROM" anymore, but "Parent" and "Children". The icon has also changed, and our user experiments tell us that it is more intuitive.
- We properly manage dependencies across baselines. Before 3.0, on a requirement in a baseline, we would only show the children dependencies, now we also show the parents.
- We don't tout it for now, but the improvement is immense.
Keys can be most UTF-8 characters
This has been in alpha-release for a long time, so we are publishing it now. Please be aware that this is still in Beta.
It is possible to create requirement keys using, for example, Chinese characters.
- The only forbidden signs are / and \,
- The inline replacement doesn't work well with enlarged UTF-8 names,
- UPPERCASE(ü) isn't always equal to Ü, depending on the database collation. Therefore, it will be possible to create both keys Aü-001 and AÜ-001,
- In the editor, the macro (the gray box) will print "%" instead of UTF-8 characters. Not nice, but expectable.
Usage metrics
You can now see a summary of your own statistics:
We don't send this data back to us, obviously.
Details
- RY-818 The "status" criteria in the search, is replaced with internal_status, because customers were confused about it.
- RY-871 Adjustment to index the Scaffolding macros
- RY-890 Clicking on "Raise a support request" now prefills the fields