There are several breaking changes in 0.3.0 when coming from the 0.2.x releases. This attempts to list the mayor changes needed to do in user code to be able to compile it with the new version.

Class name changes

  • All expression nodes (Expr suffixed classes at cron4s.expr package) have been renamed with a Node suffix instead.
  • cron4s.expr.AnyExpr has been renamed to cron4s.expr.EachNode. The new name reflects better the semantics of the * inside a CRON expression.
  • cron4s.types package has been renamed to cron4s.base
  • cron4s.types.HasCronField has been renamed to cron4s.base.Enumerated and it’s no longer higher kinded.
  • cron4s.types.IsFieldExpr has been renamed to cron4s.expr.FieldExpr.
  • cron4s.ext.DateTimeAdapter has been renamed to cron4s.datetime.IsDateTime.

Public API operations

Errors

The type cron4s.ParseError that used to be returned from the Cron("...") factory method has been replaced by a sealed class family. The old type was exposing some model objects from the internal parser implementation whilst the new one offer a cleaner foundation.

The new error types are meant to make user easy to distinguish if a given error was caused by a problem during parsing or due to validation constrains.

DateTime operations

CRON operations on DateTime representations have been unified for the three types of CRON expressions supported (full, date only, time only). The built-in library support has been moved underneath the package cron4s.lib. This means that, if wanting to use the Java 8 time support, the user will need these imports:

import java.time._
import cron4s._
import cron4s.lib.javatime._
Individual fields

The DateTime API provided by individual expression fields has suffered a minor change to provide collisions with other operations also available at the field level. For example, given the following inputs:

val cron = Cron.unsafeParse("10-35 2,4,6 * ? * *")
// cron: CronExpr = CronExpr(10-35, 2,4,6, *, ?, *, *)
val dateTime = LocalDateTime.of(2016, 12, 1, 0, 4, 9)
// dateTime: LocalDateTime = 2016-12-01T00:04:09

There were cases in which users could find a compilation error when using the operations next, prev and step in individual field expressions when used with DateTime objects. This was due to the existence of operations with the same names that take an Int as their parameter, leading to an overloaded method situation in which sometimes the compiler refused to resolve the implicit that enable to perform such operation in the DateTime object:

cron.seconds.next(dateTime)
// error: type mismatch;
//  found   : java.time.LocalDateTime
//  required: Int
// cron.seconds.next(dateTime)
//                   ^^^^^^^^

To solve this problem the methods that operate on DateTime objects have been renamed including the In suffix:

cron.seconds.nextIn(dateTime)
// res1: Option[LocalDateTime] = Some(2016-12-01T00:04:10)

This aligns them with the previously existent matchesIn method.