/
Release 3.1 – Minor removals (Guide)

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-978 Added search criteria: pageHistory and links, and slightly modified the "page ~ ..." when it dealt with archived versions of pages.

  • RY-958 Fix an indexing error (see RY-908), which modified the dependencies in archived requirements, when modifying a current version of them.

  • 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.

  • RY-971 Error on the Excel viewer, with Oracle, when a document is bigger than 1000 items.

Feature removals

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

Slightly modified the "page ~ ..." search criteria

See RY-978: Before 3.1.0, it would search for all requirements on any version of the page. After the release, it would only search for requirements on that version of the page.

If you need the old behavior, please use "pageHistory = ..." (see Search Syntax).

Baselines: Synchronization with page titles 

Feature removal

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,

  • Feature removal 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.

  • Feature removal We don't suggest to add dependencies automatically.

  • We require to have a record in the database for this baseline,

  • Feature removal 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.

  • Feature removal A bug used to allow to create cross-space baselines. It was neither intended nor working properly, and it was removed.

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

Feature removal 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.

Baselines: What are the remaining features?

Most of them!

  • You can create a baseline from 3 places: From a page ("instant baselines"), from the search, and from the "RY Baseline" blueprint.

  • We memorize the requirement, its properties and its dependencies. We create an archived version of each page, so you can always see the requirement in context.

  • Concerning dependencies, it is not always possible to navigate properly across baselines, so we recommend to baseline all relevant requirements, or precisely test your intended usecases using examples.

  • Images are not baselined. We only save the URL, and the image can be swapped out.

  • The links to Jira are not baselined.

  • You can refreeze a baseline and add/remove/update requirements. If a requirement is not updated, we don't create an archived version for it, which may be misleading when viewing this requirement again.