I agree we have a pain point here. gremlin-scala and Ogre have solved this problem by adding a 4th version number. you would therefore have E.X.Y.Z where the "E" is the TinkerPop version epoch (i.e. the "3") and then the X.Y.Z could move as you say. Some issues that would need to be addressed come to mind:
+ I suspect this sort of change would alter our branching strategy a bit. We'd need one branch per "Y" per language. I suppose those would just be created as needed from the release tags. + we would need to come up with a different release tag strategy as well, where we prefixed/suffix the version with the language for the tag name. + i assume the Java libraries outside of gremlin-driver retain the standard 3 digit version and we'd have just E.X.Y for them + under this model where gremlin-driver is more separated in it's release, i'm not sure what that means for the dependency tree of gremlin-server. gremlin-server depends on gremlin-driver (for serializers mostly i think). maybe that's a non-issue as any 4-digit Z change in the gremlin-driver would end up being merged through (in some fashion) to the latest gremlin-server 3-digit Z. + afaik, there are no troubles with having a child pom with a different <version> from the parent, but we'd have to confirm that. You didn't suggest it, but I'd just make the point that I'd be against breaking up the project into multiple repositories at this time. We have too much good automation, test integration, etc. to let all that go. On Mon, Sep 27, 2021 at 11:29 AM Divij Vaidya <[email protected]> wrote: > 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 >
