REPOSITORY CODING · EASY
Release choices put version 1.10 before 1.2
The supported-release list uses text ordering. Repair numeric ordering and minimum-version filtering while retaining validation and compatibility checks.
Architecture ExtensionRelease compatibility and maintenance planner
Work through a real codebase.
Choose an environment, investigate the existing implementation and use the tests to check your change. Sign in to open a workspace; execution and Ono usage follow your plan’s allowances.
Task requirements and environments
Java · 35 minute session
- A catalogue contains at most 12 releases and 32 directed upgrades. Versions are three numeric components (0..999999), without leading zeros, labels or prerelease suffixes. Compare each component numerically.
- Each release declares platforms and capabilities. Only non-withdrawn releases supporting the requested platform and every required capability can appear anywhere in a plan, including start and target.
- Each upgrade has a unique ID, known distinct endpoints, positive integer minutes, and integer downtime between zero and minutes. Edges need not go to a higher version: rollback edges are allowed.
- The list operation returns eligible version strings at or above minimum, in numeric order. The plan operation returns versions, upgrade IDs, total minutes and total downtime, or null when no path fits.
- A plan must stay within the cumulative downtime budget. Minimize total minutes, then total downtime, then the lexical upgrade-ID sequence. Multiple arrivals at one release may need to remain candidates because their downtime differs.
- Planning is stateless and does not perform migrations. Invalid data returns {ok:false,error:<code>}. Successful results use {ok:true,value:<result>}. All test fixtures are visible.