3.6.0.1
>> 3.6.1
>> 3.6.1.1
>>
>> That would be a reason I see against the 4 part versioning scheme,
>> although we could of course still adopt it only for some GLVs.
>>
>> -Ursprüngliche Nachricht-
>> Von: Divij Vaidya
>> Gesendet: Freitag
---Ursprüngliche Nachricht-----
> Von: Divij Vaidya
> Gesendet: Freitag, 29. Oktober 2021 11:12
> An: dev@tinkerpop.apache.org
> Betreff: Re: [DISCUSS] Separate versioning and release cycle for clients
>
> Stephen,
>
> Your proposal for E.X.Y.Z sounds good to me. To clarify th
of course still adopt it only for some GLVs.
-Ursprüngliche Nachricht-
Von: Divij Vaidya
Gesendet: Freitag, 29. Oktober 2021 11:12
An: dev@tinkerpop.apache.org
Betreff: Re: [DISCUSS] Separate versioning and release cycle for clients
Stephen,
Your proposal for E.X.Y.Z sounds good to me. T
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
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 c
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, Steph
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
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
