While I am not suggesting we do this the advantage of making separate repos is that it becomes much less daunting for newcomers to contribute. Right now it is a big beast with tons of projects that make it difficult to know where to begin.
Dave Bechberger > On Sep 28, 2021, at 4:07 AM, Stephen Mallette <[email protected]> wrote: > > 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 >>
