Skip to content

Conversation

sam-maloney
Copy link
Contributor

Problem: if a non-default operator or operand are specified, then max would also need to be given, making it more difficult to specify an unbounded range with non-default operator/operand combinations

Make the max key always optional independent of the the other keys, change to require only the operator/operand keys be specified as a pair, and clarify their default values if unset

RFC14 update to align with flux-framework/flux-core#7130

Problem: if a non-default `operator` or `operand` are specified, then
`max` would also need to be given, making it more difficult to specify
an unbounded range with non-default `operator`/`operand` combinations

Make the `max` key always optional independent of the the other keys,
change to require only the `operator`/`operand` keys be specified as a
pair, and clarify their default values if unset
Copy link
Contributor

@grondo grondo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks!

@mergify mergify bot added the queued label Oct 13, 2025
@mergify mergify bot merged commit c315196 into flux-framework:master Oct 13, 2025
7 checks passed
@mergify mergify bot removed the queued label Oct 13, 2025
@sam-maloney sam-maloney deleted the rfc14-max-key-optional branch October 13, 2025 14:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants