Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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

Ad-hoc solution for testing




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.

Deprecated behaviors

We are not going to support "live" macros in the future, ie macros which can change the contents of pages after leaving the editor. Requirements should be defined on normal pages and always be rendered the same way as soon as the page is displayed. It means we won't support:

  • Page generators such as Scaffolding,
  • Dropdowns where the status can be selected, unless they modify the actual storage format of the page,
  • Macros which retrieve the status from another system.

Concerning Comala workflows, we may publish a separate tool to write the Comala status inside an external property on macros.

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


  • No labels