event_type reserved now explicitly means taking possession

[dirkdk]

Explain pull request

The status_change event_type reserved has caused confusion (see #417). More and more providers support reservation as in future hold for a vehicle. It seemed that reserved was actually not meant for this use case, but just for taking possession. The requirement to have a trip_id hints at this. This PR more explicitly states the intent of the event_type reserved to be only when a user takes physical possession of the vehicle, not to reserve for future use.

Is this a breaking change

Although the API definitions strictly remain the same, both API clients and implementations may have to be adjusted.

• I'm not sure

Impacted Spec

• provider

Additional context

Agency has trip_start and reserved, this means that Provider reserved is comparable to Agency trip_start

[claassistantio]

All committers have signed the CLA.

[thekaveman]

Good clarification of the original intent. A follow-up PR to bring some notion of future-hold reservations is probably warranted for a subsequent release.

[thekidder]

What happens when a device is reserved but not yet in a customer's possession? Should the vehicle remain in the available state, despite the fact that it is not rentable?

I think it would be helpful to add a new event_type_reason for the unavailable state to address this.

A proposal to clarify this, though it is a breaking change:

• Rename the existing reserved event_type to on_trip or similar
• Add a new reserved event_type_reason to the unavailable state.

This accurately captures the distinction here.

[Retzoh]

What happens when a device is reserved but not yet in a customer's possession? Should the vehicle remain in the available state, despite the fact that it is not rentable?

I think it would be helpful to add a new event_type_reason for the unavailable state to address this.

A proposal to clarify this, though it is a breaking change:

• Rename the existing reserved event_type to on_trip or similar
• Add a new reserved event_type_reason to the unavailable state.

This accurately captures the distinction here.

This would re-conciliate the provider and agency APIs as far as trip and reservation are concerned. We could event add a cancel_reservation to the available state.

(linking to #271)

[marie-x]

@Retzoh trip would match Agency. I think adding trip and change the meaning of reserve would be good in the 0.5.0 timeframe.

[thekaveman]

We decided on the 1/30 call that this change might in fact break historical data created under the ambiguous understanding/definition of reserved. We will keep the PR around for posterity but will not merge and look for @dirkdk to submit a follow-up with perhaps a note calling out the ambiguity for 0.4.1.

[dirkdk]

closing this for PR #439