Upgrade guide

Versioning

Nextmv code releases follow semantic versioning. To upgrade or downgrade Hop, for example, replace <VERSION> with the semantic version you want to depend on (e.g., v0.8.0).

go mod init
go get github.com/nextmv-io/code/hop@<VERSION>

Nextmv v0.8.0

Update import paths for dash, engines, and third-party extensions

We’ve added Dash to the code monorepo on GitHub. The new import paths must be reflected in your go get command.

go get github.com/nextmv-io/code/dash

We have renamed HopM to engines. The new import paths must be reflected in your go get command.

go get github.com/nextmv-io/code/engines

We have moved extensions to a new suite of modules, called extend. This includes modules which use third-party dependencies such as AWS Lambda or OSRM. This may be a breaking change as these same features used to be part of dash, hop and hopm (now engines). This means import paths have changed (e.g., github.com/nextmv-io/code/hopm/measure/osrm is now github.com/nextmv-io/code/extend/measure/osrm) and this must be reflected when using the go get command.

Upgrade Hop to use ALNS (Adaptive Large Neighborhood Search)

ALNS is now supported in the vehicle and fleet engines by default. No additional upgrade steps are required to use ALNS for users employing vehicle.DefaultSolver(state, opt) or fleet.DefaultSolver(state, opt). However, for users employing solve.Minimizer(outputState, opt), solve.Minimizer(outputState,opt) will need to be replaced with vehicle.Solver(root, opt) or fleet.Solver(root, opt) to use ALNS in the vehicle or fleet engine, respectively.

Default operators and parameters are provided for use with ALNS. Custom inputs are supported if required. See the package docs for additional details. Further support will be provided for ALNS in vehicle and fleet engines in future releases.

Add new Context.context argument to select Hop and engines methods

A context.Context argument must been added when calling implementations of the following methods in Hop:

• model.State.Next()
• solve.Solver.All()
• solve.Solver.Last()

And to the following methods in engines:

• fleet.Router.Feasible
• fleet.Router.Optimal
• fleet.Router.WarmFeasible

Nothing is required beyond adding the argument.

Add service and wait times to window measures

Service times durations []int and maximum waiting times before each window waitMax []int now need to be provided when constructing a window measure. Previously, service and waiting times were part of a measure. Now, times are provided to a measure. This enables the specification of maximum wait time, for example.

Pass in a function when using CustomRouter

When using a CustomRouter, a function must now be passed in for each phase. Two new default functions are available for use (these are used for the DefaultRouter):

• fleet.SolverFuncGenerator
• fleet.AlnsSolverFuncGenerator

Add or remove UnassignedPenalties (depending on desired behavior)

Default UnassignedPenalties behavior has changed:

• If no unassigned penalties are provided, assignment will be enforced (note, this could result in no feasible solutions being returned).
• If unassigned penalties are provided, assignment will not be enforced. Unassignment will be discouraged (more or less, based on the penalty value).

If using a penalty to prevent unassigned locations, it is advised to remove it in order to benefit from the new default behavior for the fleet engine: if no UnassignedPenalties are provided, all locations are assigned a vehicle. Note, the enforcement of assignment could result in no feasible solutions being returned. To discourage (but still allow for some) unassigned locations, we suggest to add unassigned penalties (see [modeling-best-practices][modeling-best-practices] for more on unassignment penalties).