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 atcron4s.expr
package) have been renamed with aNode
suffix instead. cron4s.expr.AnyExpr
has been renamed tocron4s.expr.EachNode
. The new name reflects better the semantics of the*
inside a CRON expression.cron4s.types
package has been renamed tocron4s.base
cron4s.types.HasCronField
has been renamed tocron4s.base.Enumerated
and it’s no longer higher kinded.cron4s.types.IsFieldExpr
has been renamed tocron4s.expr.FieldExpr
.cron4s.ext.DateTimeAdapter
has been renamed tocron4s.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.