Release 3.1 – Minor removals (Guide)

Migrating from Requirement Yogi 2.x?

If you are migrating from Requirement Yogi 2.x, the migration tasks will execute. It is generally fast and seamless, but some customers can experience errors, see Migration to RY 3.0: FAQ for all the details.

This release could have been a "bugfix" version, but we've decided to make it a major one to emphasize the removal of 1-2 small features.

Baselines have changed

Continuing our enterprise-scale goals, baselines are now a long-running task, running in the background:

We had to adapt a few things in the wizards (see "Feature removals"),
This feature may not feel important for you, but it will allows us to increase the size of baselines in the future by 100-fold or more. We have experiments with baselines of more than 1 million requirements. We keep the limits as usual for now, until the model is polished (equal to the global limit, 12000, configurable).
The UI has changed a little bit, to display the progress bar, in the 4 places where baselines can be created.

Requirements are generated using an internal table

It should be invisible to users, except from edge cases. Requirement keys used to be suggested by querying the whole database and finding the next gap in requirement keys. It would be very slow, sometimes several seconds.

The new algorithm stores the last generated key, a bit like a sequence in SQL. It means suggestions should be extremely fast (we've seen 200ms instead of 25s in some cases).

Edge cases:

If a customer removes keys, we won't search for "gaps" between already-assigned keys,
If you switch the settings between "reassign deleted keys" and "do not reassign", then the table is already populated.

Performance improvements

Those improvements were made in the context of obtaining the Data Center yearly approval.

RY-959 Add a maximum size to caches,
RY-960 Set caches to replicate through invalidation when possible.
RY-964 Reduce all transactions to 5s, particularly in background tasks.
RY-970 Autosuggestion of requirement keys: Add a column in the table for the uppercase of the requirement
RY-962 Autosuggestion of requirement keys: Store generated keys in a table (as if they were DB sequences) instead of search tables manually. This greatly accelerates key generation.
RY-979 Enable administrators to set limits to export sizes, by upgrading to PSEA 1.7 if they want.

Bugfixes

RY-968 Fix an error in the viewer for Excel documents,
RY-969 In the Jira Bulk Issue Creation, fix an error when clicking "Reapply"
RY-972 Search syntax: The NOT keyword is incorrectly applied when used with parenthesis.
RY-976 Excel imports: Properties were not imported.

Feature removals

They should be minor, but we want to help you communicate with your users.

Baselines: Synchronization with page titles

Some baselines are linked to a Confluence page, which summarizes it. We used to synchronize the title of the page and the one of the baseline. It was a costly feature in terms of performance because we would have to watch all pages in Confluence. We have removed this synchronization. If you want to rename both a page and a baseline, use the rename feature on the baseline tab:

Baselines: The wizard has changed, with a few steps in the process

In any place where we create a baseline (the wizard, the baseline macro in the blueprint, the instant baselines, and the refreeze):

There is a progress bar,
The requirement count is approximate when refreezing from another baseline, because we are not able to calculate in-memory the difference between the old baseline, and the added/removed requirements.
We don't suggest to add dependencies automatically.
We require to have a record in the database for this baseline,
For "instant baselines" (baselines created about a single page in Confluence), we used to create an associated page to summarize the baseline, and we don't do that anymore. If you need this associated page, then create the baseline using the search and the wizard.

Example with the Baseline blueprint:

Step 1. The baseline summary page (Fresh page with the RY Baseline macro)
Step 2. After the first click The record is created in the database. The number of expected requirements is fixed. The query is fixed.
Step 2 bis. Need to change the query? If you change the query on the page, the record of the baseline won't be updated, since it is already created. If you need to update it, click "Recount" on the previous screen.	then click Recount.
Step 3. Freeze When clicking "Freeze requirements", a progress bar appears.
Step 4. Final The two lines are a single component, it is not possible to display the baseline name or status alone.

Example with the baseline wizard:

Step 1. Search In the search, click Make baseline.
Step 2. Choose the name A title for the baseline will be automatically suggested.
Step 3. Check the dependencies This step suggests the dependencies which are going out of this baseline. Feature removal: We don't display this step when the baseline is large (more than 1 page of results, i.e. 600 requirements), because it is impossible to calculate the results with accuracy without using large amounts of memory. We keep this step for legacy and educational reasons. Feature removal: There used to be an "Add" button for the dependencies, there isn't anymore.
Step 4. Choose options In the past, the user could choose to freeze now or later; Now, we have 2 options to choose.
Step 5. The progress bar Like in the other situations, the "Create baseline" of the previous screen will create a record in the database, then display a progress bar, then a final state as seen in the screenshot.

Baselines: We don't suggest the dependencies anymore

As seen in the Step 3 above:

Suggestions to add dependencies in baselines can't be accurate anymore, if we want to keep the memory footprint small for Data Center instances,
Therefore, we don't suggest dependencies if the baseline is large (>600 requirements) or if it is a refreeze.

That's all. We have tried to keep changes almost seamless in 3.1 compared to the version 3.0, and we have removed the minimum, and we hope that we will not inconvenience your users too much. These changes were required to avoid loading large amounts of requirements in memory, and Data Center administrators will certainly appreciate the change.