On testing, I don't think increased flexibility changes our responsibility to test beyond a single, fixed version i.e. supported version. Of course, some poor soul could volunteer to manually run the tests against 3.x (or whatever versions) before a release just as a quick compatibility check. If the test doesn't pass, the release doesn't stop, that version is just marked as incompatible.
Robert Dale On Mon, Nov 21, 2016 at 10:28 AM, Stephen Mallette <spmalle...@gmail.com> wrote: > Personally, I'd rather not include neo4j in our packaging of the > console/server. I'd prefer to completely leave it up to users to decide if > they want any aspect of neo4j in their distribution. So I guess if I was > considering that I would be looking at: > > install org.apache.tinkerpop neo4j-gremlin 3.2.3 > install org.neo4j neo4j-tinkerpop-api-impl 0.3-2.3.3 > or > install org.neo4j neo4j-tinkerpop-api-impl 0.4-3.0.3 > > If we went that route, I would say it would definitely be a change for > 3.3.0. I like that we can drop the manifest entry - that's good. The double > "install" command kinda stinks, but it doesn't really bother me all that > much. Not sure if others have opinions. I don't see neo4j dependency stuff > moving up to <dependencyManagement> in the parent pom as a bad move. > > Allowing this though means we now have to actually test/maintain multiple > versions of neo4j. We've not done that before. Do we want the additional > work of maintaining multiple versions? If so, how do you test with both > versions? Two separate maven profiles i guess? I don't imagine they could > be run together in the same build either, right (you'd need to run the > build with one profile then again with the second)? > > On Mon, Nov 21, 2016 at 10:07 AM, Robert Dale <robd...@gmail.com> wrote: > > > Or maybe leave the version up to the user. If we remove the plugin dep > on > > the impl from neo4j-gremlin, then we can say "Tested on x. Feel free to > > install any impl that implements neo4j-tinkerpop-api version y". I think > > that's where the logical boundary is anyway. Of course, installing > becomes > > a two step process instead of one. > > > > install org.apache.tinkerpop neo4j-gremlin 3.2.3 > > install org.neo4j neo4j-tinkerpop-api-impl 0.3-2.3.3 > > or > > install org.neo4j neo4j-tinkerpop-api-impl 0.4-3.0.3 > > > > However, at that point neo4j-gremlin could just be included since there's > > no longer a license issue. Then we're back to a single install step. > > > > install org.neo4j neo4j-tinkerpop-api-impl 0.3-2.3.3 > > or > > install org.neo4j neo4j-tinkerpop-api-impl 0.4-3.0.3 > > > > Could also add a link to available versions - http://search.maven.org/# > > search%7Cga%7C1%7Ca%3A%22neo4j-tinkerpop-api-impl%22 > > > > I think the other benefit here is that it simplifies the neo4j-gremlin > pom. > > The manifest entry can be removed which also removes duplicate version > > info. Not that it's a great burden or anything but they should be kept in > > sync. Any reason why the neo4j version property and dep management > > couldn't be pushed to the parent pom? That is stuff that could be shared > > between gremlin-server and neo4j-gremlin. > > > > WDYT? > > > > > > Robert Dale > > > > On Sat, Nov 19, 2016 at 7:29 AM, Stephen Mallette <spmalle...@gmail.com> > > wrote: > > > > > OK - 3.3.0 is fine by me. maybe better to do a big upgrade of neo4j on > a > > > big release of ours. > > > > > > On Fri, Nov 18, 2016 at 3:45 PM, Robert Dale <robd...@gmail.com> > wrote: > > > > > > > One reason to not upgrade the version in existing release trains is > to > > > not > > > > force anyone to upgrade their neo4j database. It's an irreversible > > > database > > > > format change from neo4j 2.x to 3.0. There may be other breaking > > changes > > > > specific to neo4j itself [1]. > > > > > > > > OTOH, there are no TinkerPop API changes so it's "easy" enough for > > users > > > to > > > > manually downgrade (or upgrade) neo4j version. So if we do upgrade a > > > patch > > > > release, like 3.2.4, then they can remain on neo4j 2.3.x. > > > > > > > > The patch will actually work down to TP 3.1. I haven't tested > earlier. > > > > > > > > 1. https://neo4j.com/guides/upgrade/#neo4j-3-0 > > > > > > > > > > > > Robert Dale > > > > > > > > On Fri, Nov 18, 2016 at 2:55 PM, Stephen Mallette < > > spmalle...@gmail.com> > > > > wrote: > > > > > > > > > Is this actually a breaking change for users that would need to go > to > > > > > 3.0.0? Any reason it can't go to 3.2.4? > > > > > > > > > > On Fri, Nov 18, 2016 at 2:53 PM, Robert Dale <robd...@gmail.com> > > > wrote: > > > > > > > > > > > Since TinkerPop 3.3.0 is introducing major changes, I figure now > > is a > > > > > good > > > > > > time to propose this update. > > > > > > > > > > > > Neo4j 3.0 was released on 4/26/2016. It's now at 3.0.7. The > > > > > > neo4j-tinkerpop-api-impl > > > > > > is also at 3.0.7 however the latest in the maven repo is 3.0.3. > > Thus > > > we > > > > > > would use the 3.0.3 version for now. I can sync-up with @jexp > > > > > (maintainer) > > > > > > to find out when 3.0.7 might be available in maven. > > > > > > > > > > > > The changes are minimal in that there are just a few cypher > queries > > > in > > > > > the > > > > > > unit tests that need parens - now required - around certain > > > parameters. > > > > > > > > > > > > Sorry, there's not a significant time savings in the integration > > > tests > > > > > ;-) > > > > > > > > > > > > Robert Dale > > > > > > > > > > > > > > > > > > > > >
