Draft

[mzuenni]

• constants (Implement constants #431)
• bt upgrade (Add bt upgrade #432, closes bt upgrade port old problems to new spec #295)
• new latex dirs (Split up problem_statement/ into statement/, solution/, and problem_slide/ #434)
• output_valdiator (Output validator #435, closes Support singular output_validator/ for 2023-07-draft spec #424)
• Add .download samples and ans_is_output flag (Add .download samples and ans_is_output flag #436)
• Update parsing of problem.yaml based on Specifying problem.yaml, small changes suggested Kattis/problem-package-format#372 ([problem] Update parsing of problem.yaml based on Kattis/problem-package-format#372 #437)
• Input/output visualizer (Draft visualizer #448)
• Legacy export (Legacy export #441)
• [validate] Remove {input,answer}_format_validators ([validate] Remove {input,answer}_format_validators #443)
• Remove support for data/bad/ (Drop support for data/bad #445)
• Rename testdata.yaml to test_group.yaml and split off <testcase>.yaml from it
  • Side-note: make sure that args and full_feedback are accepted when parsing, but we don't need to implement them per se (we should warn if we indeed don't)
• Move *.hint and *.desc to <testcase>.yaml keys hint: and description:
• If we feel like it: properly check combinations of license and rights_owner (see Clarify rights owner Kattis/problem-package-format#391 and [problem] Update parsing of problem.yaml based on Kattis/problem-package-format#372 #437 (comment))
• Extend parsing of persons in credits to a map of strings: Allow person (in credits) to be specified as a map Kattis/problem-package-format#415

Not part of the spec, but now that we're changing things anyway:

• Rename testsession in contest.yaml to test_session

New features to BAPCtools that can also be added separately from upgrading the current implementation from legacy to 2023-07-draft:

• static_validator
• expectations @thorehusfeldt (see also Implement Feat/expectations #307 and Submissions and expectations #412)

[mzuenni]

Move *.hint and *.desc to testcase.yaml keys hint: and description:

do we want to move those keys or add a new key yaml here that gets written verbatim?

[mpsijm]

Good question, I think the latter. Since <testcase>.yaml contains more keys (see the spec), I think it makes sense to have a key yaml that contains this extra configuration, since this configuration should be written to a .yaml file with the same base name as the test case. So, we could have something like this, where we get 1.in, 1.ans, and 1.yaml:

data:
  sample:
    "1":
      in: Hello
      ans: World!
      yaml:
        args: -n 42  # This makes no sense in the Hello World example, I just wanted to spam all the keys 😛
        input_validator_args: case_insensitive
        output_validator_args: case_insensitive
        full_feedback: True
        hint: Greet the world!
        description: A test case in which the world is greeted.