Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add changes in RecurrenceGoal to 2.19 upgrade guide #186

Merged
merged 1 commit into from
Sep 11, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions docs/upgrade-guides/2-18-0-to-2-19-0.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,19 @@ This is an early-release feature which may see some significant changes in futur
Two new database migrations have been added to support Procedural Scheduling. If you are upgrading from a past version and want to preserve your data, follow the instructions in the
[Database Migrations Guide](../deployment/advanced-database-migrations.mdx) to apply migrations after upgrading. Make sure to either pass the `--all` flag, or apply **both** migrations interactively.

## Breaking Change to RecurrenceGoal functionality
The behavior of the `RecurrenceGoal` has been changed when setting its `interval` parameter.

When setting the `interval` parameter to 1 hour, the old behavior would create 1-hour bins for the duration of the horizon (or the more restrictive applyWhen period) and place 1 activity in each of these bins, whenever it is possible considering global scheduling conditions, behaviour which could have resulted in intervals of >1 hour between consecutive activities. With the new behavior, the `interval` parameter means a strict 1-hour distance between consecutive activities.

New parameters have been introduced to give more control over the behavior of the goal and how it is solved:
- A user can now give lower (`separatedByAtLeast`) and upper bounds (`separatedByAtMost`) on the separation between activities. Only the upper bound will lead to conflicts being created. In other words, having activities separated by less than `separatedByAtLeast` will not create a conflict. But, when a conflict exists, `separatedByAtLeast` will be used for solving.
- As said above, the old `interval` parameter has been left but setting it to X is equivalent to setting both `separatedByAtMost` and `separatedByAtLeast` to X.
- The user can either use the `interval` parameter or the 2 new bounds parameters.
- Another new parameter `previousActivityStartedAt` allows the user to specify when the “last” activity happened. It can potentially be a negative duration if it is before the start of the planning horizon. If not set, this parameter is set to `-separatedByAtMost`.

The solver will now try several combinations to solve this goal, starting with the least number of activities possible (separated by a greater distance), and increase the number of activities until either all the temporal constraints are satisfied or it reaches a dead-end.

## Scheduling plan spec schema refactor (breaking change)

The primary key for `scheduling_specification_goals` has been updated to a new unique auto-incrementing integer: `goal_invocation_id`. This is to allow multiple "invocations" of the same goal definition in a plan spec.
Expand Down
Loading