Hi Stephen, Could we make the argument that a 3.7.1 driver would only serialize and send a DT to the server if the is using these new date steps in their traversal. Regardless of serialization considerations, this is a use case which would not be expected to work as a 3.7.0 server/graph would not have these steps. The bytecode question here does not appear to be introducing a new incompatibility as much as it is shifting the point of failure of an expected limitation when adding new steps.
I understand that historically TinkerPop has shied away from any serialization changes whatsoever during minor version releases. However, I might argue that as long as a 3.7.1 client and 3.7.0 server (and vice versa) are completely compatible as long as there are no attempts to use the new date steps, then I wouldn’t expect such an inclusion to break any users’ expectations of compatibility. Regards, Cole From: Stephen Mallette <spmalle...@gmail.com> Date: Tuesday, September 19, 2023 at 8:12 AM To: dev@tinkerpop.apache.org <dev@tinkerpop.apache.org> Subject: Re: [DISCUSS] Including date functions in 3.7.1 release this needs to land in the next major and not 3.7.1. No one will use DT as a property value but they will use it in a traversal and when that is serialized as bytecode the server will fail to know how to deal with it. On Mon, Sep 18, 2023 at 2:37 PM Valentyn Kahamlyk <valent...@bitquilltech.com.invalid> wrote: > Hi all, > > I implemented the new date functions as described in Dave's proposal > > https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/proposal-3-remove-closures.asciidoc > . > As part of this task, I added a new data type DT to represent time > intervals such as minute, hour, day. Formally, this is a breaking > change because version 3.7.0 clients will not be able to read data if > DT is used as a property value. I think this is not a viable use case > and suggest merging these changes into 3.7.x rather than creating 3.8 > or 4.0 branches and delay date functions release. > Does anyone have any concerns about including this into 3.7.x? If no > one raises any objections within 72 hours, then I will assume lazy > consensus and merge in my PR > https://github.com/apache/tinkerpop/pull/2223. > > Regards, Valentyn. > Warning: The sender of this message could not be validated and may not be the actual sender.
