Stephen, Your proposal for E.X.Y.Z sounds good to me. To clarify that we are on the same page, let me re-iterate the versioning and release process:
1. Z is reserved for urgent upgrades such as security patches or major bug fixes. 2. A client with a specific E.X.Y will be backward compatible with user application code written for E.X.Y. 3. A client with specific E.X will be backward compatible with the E.X version of the server. Release: 1. Clients (may) follow a different release cycle than server which implies it is possible to have Java client v3.4.14 released without having 3.4.14 release for server or other components. 2. E.X.Y will be a release tag specific to the client e.g. 3.4.14-Java. A separate branch would be created from the release tag on demand if new patches need to be applied to increment Z (which should be rare). 3. E.X.Y version of a server will use the latest E.X.latestY version of the client for integration testing. Sounds right? Divij Vaidya On Tue, Oct 12, 2021 at 2:10 PM Stephen Mallette <[email protected]> wrote: > 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 > > >> > > >
