loopback/3.0-RELEASE-NOTES.md

# List of notable changes made between 2.x and 3.0

All breaking changes must be described here. When adding a new entry,
always describe the impact on users and instructions for upgrading
applications from 2.x to 3.0.

## loopback-datasource-juggler was moved from peerDependencies to dependencies

Originally, we (ab)used peer dependencies to ensure there is only one instance
of loopback-datasource-juggler in the dependency tree, so that there is only
one singleton instance of model registry. This was very fragile and might not
have worked in certain edge cases.

We have reworked loopback-datasource-juggler and connectors to not rely on
a single juggler instance anymore. As the last step, juggler became a regular
dependency.

https://github.com/strongloop/loopback/issues/275

When upgrading application from previous loopback versions, simply remove
loopback-datasource-juggler from your dependencies.

## always use bluebird as promise library

In version 3.0, we always use bluebird as our promise library
instead of `global.Promise`.
We consider Bluebird API a part of LoopBack API from now on,
you are welcome to use any Bluebird-specific methods in your applications.

If you are using LoopBack with a custom promise implementation provided
via `global.Promise`,
you will have to check all places where you are using non-standard promise API
and update them to use Bluebird API instead.

Please see [Related code change](https://github.com/strongloop/loopback/pull/1896) here.

## new method of defining remoting metadata

In 2.0, remote methods were defined as:
```
methods: {
  staticMethod: {
    isStatic: true,
    http: { path: '/static' }
  },
  instanceMethod: {
    isStatic: false,
    http: { path: '/instance' }
  }
}
```

For 3.0, the isStatic flag is no longer required and will be determined from the method name.
Method name starting with "prototype." will be the same as having isStatic flag set to false.
```
methods: {
  staticMethod: {
    http: { path: '/static' }
  },
  'prototype.instanceMethod': {
  http: { path: '/instance' }
}
```

Please see [related code change](https://github.com/strongloop/loopback/pull/2174) here.

## remove `Change.handleError`
`Change.handleError` is now removed as it was used inconsistenly for a subset of possible
errors only. All Change methods will report all errors to the caller via the callback.

Use PersistedModel to report change-tracking errors via the existing method
PersistedModel.handleChangeError. This method can be customized on a per-model basis to
provide different error handling.

Please see [related code change](https://github.com/strongloop/loopback/pull/2308) here.