Hello all *Summary* I would like to propose that we start releasing clients/drivers with their own versioning separate from the overall TinkerPop release. Separate release cycles and different versioning schemes for clients will lead to faster release iterations.
*Details*Currently, TinkerPop is released as one software including the clients, the query engine, the server and other associated components. This boxed versioning ensures that all artifacts bundled in a release are compatible with each other. This is a good approach with an eye towards maintaining version parity and making it easier for users to get started with using TinkerPop. However, some recent changes in the client have surfaced problems with this approach. *Terminology*If a version is X.Y.Z, X is referred to as the major version number, Y is the minor version number and Z is the micro version number. *Problem:* The problem with the above versioning arises when newer clients are still compatible with older TinkerPop servers, but there is a change in application facing contract. This makes them backward-in-compatible with the existing code in user application. As per current release policy, we would wait for the next "minor version" change to release the newer version of the client with a modified contract. The "minor version" change characterizes breaking changes in the Gremlin language semantics or server APIs. Due to this coupling between clients and server release, an application facing contract change in the client will not land in the hands of the user until overall TinkerPop's minor version is changed. As an example, PR-1479 <https://github.com/apache/tinkerpop/pull/1479> and PR-1465 <https://github.com/apache/tinkerpop/pull/1465> modify the application facing contract for the Java client. One of them changes the exception thrown from client APIs and the other one deprecated a configuration. Ideally, I would have liked to see them released as 3.6.x (current stable versions are 3.5.x and 3.4.x) ASAP to land these changes in the hands of users. *Proposal:*Clients should follow their own versioning scheme and separate release cycle. It is possible for each language client to be on a different minor version at any given time e.g. the latest release of python could be 3.4 and for Java it could be 3.7. Proposed versioning contract: 1. Every client with the 3.* version will work with the 3.* version of the TinkerPop server. 2. Every 3.A.* (where * is a placeholder for micro version increase) version of a client will work with user application code written with a contract for 3.A clients. Such micro version bumps are reserved for security patches or critical bug fixes. 3. Whenever language semantics or results for the language change, it should be a true major version increase i.e. server version moves to 4.x. *Alternative proposal (not preferred):* Alternatively, we can increment the major version whenever a breaking change occurs across any TinkerPop component. This is not preferred since this mechanism doesn't dis-ambiguate what component has broken the contract. As an example, for some users it might be acceptable to upgrade to the new client's contract with their application but they might not want to pick up the changes in the server associated with that upgrade. Thoughts? Regards, Divij Vaidya
