Just wanted to revive this thread a bit: Divij, did you have any thoughts on my suggestions?
Dave, I'm coming around to that way of thinking but feel a bit blocked by at least two points. How would we structure things in a separate repository if we were to do that, keeping in mind that: 1. You can't really test the code without Gremlin Server and you're not typically working off of a particular static version of Gremlin Server but from whatever is most current in the git repo for a particular branch. 2. The current testing model that builds off the grammar yields us round-trip testing in a single mvn clean install. With that command we parse the documentation and all the feature files for Gremlin, run them through the translators, which generates a Gremlin test file in whatever the native language is, which then is compiled/evaluated natively during the test phase validating both the translation of all that Gremlin as well as the execution of all that Gremlin. We'd need to come up with a way to not give up too much of that convenience and testing if we were to spin out to other repositories. Another alternative that could be considered would be to retain the single repository but restructure it somehow to be a bit easier to consume. Potentially this could exclude the maven integration, but we'd still need to satisfy items 1/2 above somehow. On Fri, Oct 1, 2021 at 10:34 AM Dave Bechberger <[email protected]> wrote: > 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 > >> >
