CMS 1.3.rc0 RELEASE NOTES

Release date: March 13, 2017

Link to the package: https://github.com/cms-dev/cms/releases/download/v1.3.rc0/v1.3.rc0.tar.gz

With CMS 1.2 we wanted to start a new process with smaller and more frequent releases. Looking at the 2 year gap between 1.2 and 1.3, it is clear that did not happen, but we are glad to be finally back!

Given the long time since 1.2, we decided to do things a bit differently, releasing first a CMS 1.3.rc0, with CMS 1.3.0 to follow up soon. In 1.3.0, we will not only include security bugs (similarly to a X.Y.1 release), but also small bug fixes if necessary.

CMS continues to be used all over the world. Since 1.2, it was used in IOI 2015, and will be used again in IOI 2017. We are also happy to mention that CMS has been used in APIO 2016 and CEOI 2015. As always, please continue to send feedback and testimonials. The full list is at http://cms-dev.github.io/testimonials.html .

We would like to thank the many people that worked on CMS 1.3! Also, we would like to apologize as the developer experience was often not optimal, especially in terms of latency of reviews and inclusion of pull requests.

What's new

A lot! To make things more organized, here are the major changes grouped by topic.

• Features to ease long running contests and CMS-based training platforms.

  • Users (contestants) now exist independently of contests.
  • ES is contest agnostic: a single ES manages the submissions of all existing contests.
  • Old executables can be removed from the database to save space.

• Installation and configuration

  • CMS works with virtualenv; thus avoiding the usual issues of using an incompatible version of a dependency.
  • To ease debugging, sandboxes are not deleted in case of errors, even if keep_sandboxes is unset.
  • Moved some configurations from cms.conf to the contest entity (IP restrictions, whether to allow hidden users, whether to allow questions.
  • IP based autologin: admins can decide to log in contestants automatically based on the IP of their machine.
  • Per-contest configuration to disable the testing interface.
  • Configuration to prevent contestants from downloading their previous submissions.
  • Unrestricted users (with no limits on submissions, useful for tests).

• Tasks types, score types and programming languages

  • Some output from managers can be translated.
  • Grouped score type allow defining groups using regexps on their names.
  • Communication tasks support multiple contestant-led programs.
  • Communication tasks work with all programming languages.
  • Plugin system for programming languages, allows admin to easily define their own and a contest to have multiple versions of the same language (e.g., for different compilers).
  • Java JDK support.
  • Haskell support.

• Performances

  • ES distributes jobs in batches whose size depends on the load: small batches under light load to optimize for latency, larger batches under heavy load to optimize for throughput.
  • Translated several queries from SQLAlchemy to raw SQL (especially in ES and SS)
  • Big speedup in the queries used when showing submissions in CWS.

• AdminWebServer

  • A new page showing all submissions in a contest.
  • Implemented real pagination for lists of submissions.
  • Desktop notifications for questions.
  • Teams and team associations can be edited in AWS.
  • Administrative accounts (including accounts with lower permissions).
  • Better forms (no duplication of create and edit, inline documentation of options).
  • Single action to download all testcases.
  • XSRF protection.
  • Admins can delete users, tasks, contests from AWS.
  • Admins can see user tests and their status.

• ContestWebServer

  • Desktop notifications for announcements and messages.
  • Suggest task names as question subjects.
  • Only allowed localizations are shown.

• Command line tools

  • Refactoring and improvements of cmsMake.
  • Refactoring the scripts to add, remove, import data. Added a lot of new one.

• Tests

  • Tests run much faster thanks to parallel startup and more workers.
  • We moved our continuous integration from a self-hosted Jenkins to Travis.
  • Added a performance test for ES.
  • Functional tests for user tests.

Incompatible updates.

• GroupThreshold does not consider any more the outcome 0.0 as success (too many parts of CMS already interpret 0.0 as failure).
• Both the database schema and the format of the dumps have changed. To update a dump, use cmscontrib/DumpUpdater.py \<name of dump\>.
• To update the schema, first dump the content with cmscontrib/DumpExporter.py, then drop and reinit the database with cmsDropDB and cmsInitDB, update the dump as before and import it with cmscontrib/DumpImporter.py
• Alternatively, we support in-place updates with the SQL scripts in cmscontrib/updaters, but the process is still manual.