Re: [TinkerPop3] 3.1.0 Update to Mutations via GraphTraversal

[Stephen Mallette <sp...@gmail.com>]

Hi David, I appreciate your concerns. Generally speaking, I think we're
being quite mindful of breaking code during upgrades, especially when
compared with our pre-Apache Software Foundation days. I think that the
committers are all considering the impact a change will have to the
community and processes (like the "breaking" label in JIRA) are emerging to
help make upgrades for vendors as simple as possible. So - I think the goal
of committers is in synch with your concerns - let me try to address your
individual points below:


> Have we made it easy for adopters to understand how we might
> break their implementations without them having to plow through every Jira
> or mailing list post?  That may be obvious to people sleeping and breathing
> the project, but not to others.
>

The addition of the "breaking" label was the first line of defense for
this.  On this mailing list, we've discussed  putting the JIRA tickets for
a release into the CHANGELOG on release and organizing those tickets in the
CHANGELOG more clearly to reflect that they are ones core interface
developers should watch (see item 3 .iii):

https://github.com/apache/incubator-tinkerpop/blob/master/RELEASE.asciidoc

I was thinking they would then visit the JIRA tickets for the detailed
notes on what changed and what could be a problem.  I was further thinking
that a comment (presumably the last one) of a "breaking" ticket would end
up summarizing the stuff the dev would have to look out for - see this
"breaking" ticket as an example:

https://issues.apache.org/jira/browse/TINKERPOP3-805?focusedCommentId=14700198&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14700198

How do folks feel about that approach for documenting the places where
vendors could have problems when they bump their pom version?  Do we need
more than that?


> I see Jiras like “gremlin virtual machine” and wonder what that really
> means.   Will this enable vendors and users? Will it broaden the platform
> support of TP3 without breaking current implementations?  Will it allow
> many graph platforms to embrace a very similar version of TP so there is an
> illusion of standardization? Are vendors broken or at a disadvantage if
> they don’t embrace the “gremlin virtual machine” concept immediately?  This
> is just one Jira in the hopper.  What about the rest?
>

My guess is that you are just using "gremlin virtual machine" as an example
- so I won't respond to the specifics of that question other than to say
that this ticket is not scheduled for any version at this point - it is
just a proposal for more discussion (note that the "Fix Versions" field is
not set):

https://issues.apache.org/jira/browse/TINKERPOP3-813

If you would like greater clarity on those items, please ask away on JIRA
or post your questions to the list by replying to Marko's original thread.


> TP users face similar challenges.  They just suffered through massive
> changes between 2.x and TP3 GA.  Maybe their lives are ultimately better,
> but if they are still waiting on their graph packages to be updated to some
> version of TP,  do they even know where to start with TP3 when new
> functions are already deprecated?


Perhaps there will be some disagreement, but I don't see deprecation as a
hard thing for folks to deal with.  If methods were simply removed and it
broke everyone's code when a release was issued, I'd call that a big
problem, but a @Deprecated method with clear javadocs on when it was
replaced and what you should do to make things right doesn't seem that
disruptive.  It is only on actual removal of the deprecated method that
folks will experience pain.  Have we completely thought through how
"removal" will work?  No (as there are no plans I'm aware of for removing
any for the foreseeable future).  If you'd like to suggest some procedures
for what we should do when we remove and how we alert the community to the
issue, please feel free to offer your ideas.


> All the old, misleading examples of
> Gremlin out on the mailing list and internet aside, are we asking users to
> digest even more changes immediately to use Gremlin ?


My vote would be to not remove any deprecated methods any time soon, so I
would fully expect all existing TP3 examples for 3.0.x to continue to work
for some time (i.e. 3.1.x 3.2.x, etc).


> Is GremlinDocs up to
> date with 3.0 GA yet? (http://gremlindocs.spmallette.documentup.com/) ?
>

GremlinDocs is my personal project.  I've not brought it up to TP3 yet.
I'm still trying to sort out what I want it to look like.  TP3 docs are
very different from TP2 and I'd like GremlinDocs to be a good companion to
them (not repetitive information).  It will likely not have the same
style/content as before, as the "steps" section of TP3 docs largely matches
the pattern GremlinDocs originally set - not much point to recreating
that.  I'm open to getting help on it from anyone who wants to contribute
some time.


> A focus on more new function to the expense of a full on focus around
> enablement of vendors, languages, platforms and users, at least for the
> moment, seems misdirected.  What focus are we getting with 3.1 and 3.2 ?
>

I can't say that I agree that our efforts since GA released are
misdirected.  There hasn't been a "full on focus around enablement of
vendors, languages, platforms and users" which sounds like a way of saying
"write more docs, blog posts, tutorials, etc", but we have fixed bugs, made
optimizations, filled gaps in the documentation, and, yes, added new
features in what I believe is a sane way that protects backward
compatibility with previous versions.  If you want to challenge "sane", I
think you have to get deeper into JIRA.  What do you need to look at to
know what's coming?  Filter on the Fix Version field for 3.0.1 and 3.1.0
and you'll see what's coming up.  There's nothing secretive about what's
being prioritized for a release and we are open to opinions.

Speaking specifically for BlueMix, I think it is worth your while to setup
an automated build of BlueMix against the two primary branches of
development in TP3 (tp30 and master).  Check for new commits on those
branches and build bluemix against that to see what happens. You'll know
quite early if something is broken and we'll be happy to help you solve the
problem when/if that happens.  If TP3 changes are breaking you all the
time, we'll need to have some discussions about that issue.

Even before TinkerPop entered incubation, I think we always worked really
well with vendors.  TinkerPop is happy to have BlueMix as one of those
vendors and I think that you'll find that these "new features" for these
slated versions are not as deadly to your development cycles or to user
adoptions as you might think.



>
> On Mon, Aug 31, 2015 at 10:17 AM, Kelvin Lawrence <
> kelvin.r.lawrence@gmail.com> wrote:
>
> > Thanks for the replies guys. I think I may have been confused by the
> >> related Jira text that Marko posted on this topic. I read it as these
> >> changes would be hard for Titan to implement and therefore I inferred
> that
> >> these were quite breaking changes. After reading Marko's reply here I
> was
> >> having trouble reconciling that with what I thought I had read in the
> Jira.
> >> Having read the Jira text again this morning I guess Marko was probably
> >> saying he only did the changes that would *not* be hard for Titan to
> do. In
> >> that case sorry for my confusion!
> >>
> >
> > Kelvin
> >
>