+1

+1

I just meant any breaking change which could also simply be that a new GraphSON version is used by default. It doesn't have to be a breaking code change in the library itself. That's simply part of

Adding new features (which requires a minor version bump) doesn't hinder users from upgrading in any way. So, I don't see why we would still maintain an older version without this new feature.: This

Hi all, We are working on a decentralized knowledge graph called Weaviate, and JanusGraph plays an important role in our software. We have a few people working on JanusGraph and they have some

I also think that we should keep the number of maintained branches / versions as low as possible, ideally only 1 branch will be actively maintained. Adding new features (which requires a minor version

+1

+1

Reviewed the docs and all looks good. +1

Reviewed the docs and all looks good. +1

Hi, Sarath and Madhan Your analysis makes sense. I did a quick test. From gremlin shell: gremlin> graph.getConfiguration().getLocalConfiguration().getProperty('index.search.solr.zookeeper-url') It

+1

+1

+1

+1

Hello, We are happy to announce that JanusGraph 0.3.1 is ready for release. The release artifacts can be found at this location: https://github.com/JanusGraph/janusgraph/releases/tag/v0.3.1 A

Hello, We are happy to announce that JanusGraph 0.2.2 is ready for release. The release artifacts can be found at this location: https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.2 A

> I'm still concerned about the number of releases which will need to be actively maintained as that keeps on increasing. I would think as long as the drivers are largely backwards compatible, you'd

Nice work, thanks for getting that done!

I meant it in following sense. We go forward with releasing first version which will be tagged as 1.0.0 Now, this would be our current set of features, and as and when bugs are found out, a new patch