Github user metlos commented on the issue:
https://github.com/apache/tinkerpop/pull/494
So in another words it is a matter of setting up the level of breakage you
want to allow between different Tinkerpop versions. I based the "minor increase
allows breaking changes" on the "feeling"
Github user metlos commented on the issue:
https://github.com/apache/tinkerpop/pull/494
@spmallette this is because right now, revapi is configured to allow
breaking changes on minor version increase. The branch builds a 3.3.0-SNAPSHOT
and is compared against the latest release - 3.2.
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/494
@metlos now that 3.2.4/3.1.6 have been released i thought i'd try to get
the TINKERPOP-1443 branch ready for a final review before merging to master.
i'm not sure if i'm doing something wrong,
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/494
I've set up the branch internal to TinkerPop:
https://github.com/apache/tinkerpop/tree/TINKERPOP-1443
@dkuppitz I tried to apply your patch but it still wouldn't build for me.
Github user metlos commented on the issue:
https://github.com/apache/tinkerpop/pull/494
Hmm, maven central seems to be taking its time - it still doesn't have the
latest revapi-java version available (which is why CI failed for the latest
commit).
But anyway, I've updated the
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/494
Ok - I'm in no rush. Let's wait until you get the new release available
before I go to make an internal branch. Thanks
---
If your project is set up for it, you can reply to this email and h
Github user metlos commented on the issue:
https://github.com/apache/tinkerpop/pull/494
I'm near a new release of Revapi that contains some important fixes (like
wrong classification of a return type change to a covariant type). So
everything I wanted to do to this PR was to update it
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/494
Thanks @dkuppitz - I wonder if the easiest thing to do right now is to
merge this work into a TinkerPop branch, make some edits so that everything is
working how we want, then re-submit the who
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/494
This is required to make it work:
```
daniel@cube /projects/apache/tinkerpop (pr-494) $ git diff
diff --git a/docker/build/Dockerfile.template
b/docker/build/Dockerfile.template
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/494
@dkuppitz note my previous comment on docker wrt this PR. do we need to
alter something in Docker to get this building there?
---
If your project is set up for it, you can reply to this email
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/494
Note that `docker/build.sh` doesn't work under on this PR. I assume we need
to change the maven version in there too?
---
If your project is set up for it, you can reply to this email and have
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/494
I sent an email to the dev list for consensus on requiring 3.2.5:
https://lists.apache.org/thread.html/9ff6c4015d7c57a187d3b66dee46dbf23797483d9bbc11f0304924a6@%3Cdev.tinkerpop.apache.o
Github user metlos commented on the issue:
https://github.com/apache/tinkerpop/pull/494
@okram the API changes seem to be due to your changes in 05bfb029. You
could try and fill out your first intentional API changes list ;-)
(Most of the below is just git extravaganza - the i
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/494
I would ignore sub-packages right now. Again, lets start off small, get
things passing, and over time, add more packages to check.
---
If your project is set up for it, you can reply to this email
Github user metlos commented on the issue:
https://github.com/apache/tinkerpop/pull/494
> org.apache.tinkerpop.gremlin.structure
> org.apache.tinkerpop.gremlin.structure.io
> org.apache.tinkerpop.gremlin.process.computer
> org.apache.tinkerpop.gremlin.process.traversal
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/494
I'm on Apache Maven 3.3.9 (latest). So I'm ok with downgrading :trollface:
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If you
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/494
i'm still on 3.0.5 - i guess i don't mind upgrading, but we should see what
others think (if anything). Do we even want to force an upgrade for TinkerPop
3.2.x? maybe this should go to master f
Github user metlos commented on the issue:
https://github.com/apache/tinkerpop/pull/494
`.travis.install-maven.sh` is a workaround I used in another project for
https://github.com/travis-ci/travis-ci/issues/4872. Trusty, which is the distro
used on Travis for Tinkerpop builds, provide
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/494
I didn't dig into this too much just yet - I did see this in the travis
logs:
```text
If you want to explicitly ignore this change and provide a justification
for it, add the foll
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/494
I think we should start this merge off by having only the following
packages be analyzed:
```
org.apache.tinkerpop.gremlin.structure
org.apache.tinkerpop.gremlin.structure.io
org
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/494
> the `ImmutablePath` method changes are internal changes
I think that's the point. It would have been an internal change if the
methods were internal, but they're public. We can assume t
Github user metlos commented on the issue:
https://github.com/apache/tinkerpop/pull/494
Yes, Java makes it somewhat difficult to properly declare "module
boundaries" - let's hope Java 9 will do that right.
But for now, it is often useful to declare certain packages as internal
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/494
I think we will need to decide what is considered NOT subject to change and
what is subject to change. For example, the `ImmutablePath` method changes are
internal changes that are "okay." Perhaps w
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/494
Whoa. This is süper cool.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wish
Github user metlos commented on the issue:
https://github.com/apache/tinkerpop/pull/494
K, finally the CI fails for the right reasons :wink:
https://travis-ci.org/apache/tinkerpop/builds/176007319#L3026
---
If your project is set up for it, you can reply to this email and have your
r
25 matches
Mail list logo
