Hi,

I would like to start a discussion about our next release(s) as there were multiple requests from the community already.

Our last release (0.6.2) was also already half a year ago (May 31) and our latest major release (0.6.0) was over a year ago in September 2021.

We also already have quite some features ready for 1.0.0 (and I probably even forgot some other important ones):

• Support for Java 11: https://github.com/JanusGraph/janusgraph/issues/2161
• Support for Cassandra 4: https://github.com/JanusGraph/janusgraph/issues/2325
• Cache performance improvements: https://github.com/JanusGraph/janusgraph/issues/3185 and https://github.com/JanusGraph/janusgraph/issues/871
• Support for TinkerPop 3.6: https://github.com/JanusGraph/janusgraph/issues/3069
• Upgrade to Log4j2: https://github.com/JanusGraph/janusgraph/pull/2890
• Use mixed indices for numeric aggregations (min(), max(), mean(), sum()): https://github.com/JanusGraph/janusgraph/issues/3202
• Lots of dependency updates which fix security issues

I think these are really substantial improvements that we should release to our users and therefore at least not wait much longer for a major release. Users have also repeatedly asked for a release that contains some of these improvements, especially the security related dependency updates.

So, are there any important issues / PRs that you definitely want to see included in the next release? Otherwise, I suggest that we set a fixed deadline of when we start the release process and everything that is not merged until then will be moved to a follow-up release.

Are there any issues that should definitely be included in a 1.0.0 release but will not be finished in the next few weeks? I think in that case we could also decide to release 0.7.0 first from master so we don’t block the release just because we have decided that the next major release should be 1.0.0.

But I think it should also not be a problem to postpone any open issues to a later major release. As Oleksandr mentioned in the thread where we decided that 1.0.0 should be next major release, 1.0.0 only indicates that JanusGraph is ready for production usage [1]. It doesn’t mean that there won’t be breaking changes afterwards (as there definitely will be).

Together with 1.0.0 (or 0.7.0 if we decide on that as the next major release), we can also release 0.6.3 from the 0.6 branch. If you see any issues that should be included in that release, then that would of course also be good to know.

Does anyone want to volunteer being the release manager for these two releases? Otherwise, I can also do it.

Regards,

Florian

[1]: https://lists.lfaidata.foundation/g/janusgraph-dev/message/1517

Hi Dustin,

sure, that will be included. I should have mentioned that probably:

0.6.3 will include all issues / PRs tagged with the 0.6.3 milestone:

https://github.com/JanusGraph/janusgraph/milestone/24

1.0.0 will include everything from the 0.6.3 milestone, and additionally everything from the 1.0.0 milestone:

https://github.com/JanusGraph/janusgraph/milestone/21

The PR you linked is included in the 1.0.0 milestone.

Hi Florian,

Would this release contain the commits in this PR - https://github.com/JanusGraph/janusgraph/pull/2904?

v/r
Dustin

Yes, a release candidate probably makes sense for the 1.0.0 release. I think we don’t need a formal voting process for a release candidate. So, if there are no objections, I start preparing such a release candidate which will also include a PR to update the version numbers on master.

If there are any issues that you think should be included in the release candidate, then please list them. Otherwise, simply everything that is merged into master until the PR that updates the version numbers is merged will be included.

Elasticsearch 8 is of course a good point. But do we need to support that directly in 1.0.0? Elasticsearch 7.17 seems to be still supported roughly until 9.0.0 gets released if I understood their EoL policy correctly [1].

Can’t we also add support for Elasticsearch 8 in a minor update, like 1.1.0 and clearly document how people need to migrate their indices if they want to update their Elasticsearch installation to v8? What I mean is that it’s only a breaking change for users who actually update to Elasticsearch 8 and then they should expect some breaking changes in general.

Or do you expect the change on our side to already be breaking so that all users have to migrate their indices, even if they stay on ES 7?

In general, I think we will end up with a release date for 1.0.0 some time in January irrespective of this if we want to publish a release candidate first and then provide users some time to try it out and provide feedback. (And nobody argued against it, so I already went ahead and created a PR for the release candidate.)

[1]: https://www.elastic.co/support/eol

Hi,

Upgrade to ElasticSearch 8 will be a breaking change in regarding to Geoshape properties because we won't have Prefix Tree indexing strategy anymore. Users will need to do migration of any indexes containing Geoshape properties because Circle shape isn't compatible with the BDB indexing strategy (the only geoshape indexing strategy available in ES 8). See: https://github.com/JanusGraph/janusgraph/pull/3268
That PR is blocked until ElasticSearch 8.6.0 is released. I would prefer including such a breaking change into the 1.0.0 release.

In December there are usually many holidays and I suspect not many people will work during holidays. I think it would make sense to make `1.0.0` release early January, so that we have time to finish several other PRs and allow more people to test it because it will include quite a few breaking changes.

Best regards,
Oleksandr

My intention here is that we try to release from master soon-ish, like in January ideally. We have features on master that were implemented about a year ago already and some dependency updates that include fixes for security vulnerabilities. These security vulnerabilities alone are something that users frequently ask about to get an update for.

Having said that, I’m completely fine with saying that we want certain features definitely in 1.0.0, like support for ES 8 or the improvements to our indexing that Florian is working on. If we however expect those things to take longer to complete, then I’d suggest that we instead release 0.7.0 first.

It’s of course not easy to predict when ES 8.6.0 will be released or when other features are in place which makes it hard to decide now how we want to proceed. But since we have already decided to first publish a release candidate for 1.0.0 and therefore have to wait until January for proper feedback and because of the holiday season, I’d say we try to aim for a release date of 1.0.0 in January. We can then come back to this in January to see which features that we’d like to have in 1.0.0 are still not ready and then decide:

1. Do we need to have these features in 1.0.0 or can we also release them later, like in 1.1.0?
2. How much more time do we expect we need to implement them?

Based on this assessment, we can then decide in January whether we can release 1.0.0 already, want to postpone it a bit or whether it will take longer until we want to release 1.0.0 and we therefore could release 0.7.0 as an intermediate release to already get most of these features out in a stable release.

How does that sound?

Regarding snapshots I will respond directly in that thread you’ve linked. I think however that release candidates still make sense irrespective of snapshots as some users might want to try out a release candidate and provide feedback on that, but don’t want to use snapshot builds. Similarly to how you described it for a final release where we simply signal stability, we also signal some kind of stability for a release candidate, even if it’s much less than for a final release.

You are right that these breaking changes regarding ElasticSearch side will be affecting only those users who want to switch using ElasticSearch 8. Users On ElasticSearch 6 and 7 won't be affected.
That said, for such a major upgrade I think it makes sense to include ES 8 support in JanusGraph 1.0.0 because I expect many people will want to switch to the newer ES version. Moreover, it looks like there is only one PR left targeted ElasticSearch 8.6.0 release ( https://github.com/elastic/elasticsearch/pulls?q=is%3Apr+is%3Aopen+label%3Av8.6.0 ). So, I would expect ES 8.6.0 coming soon but can't guarantee that because I don't know their deadline. I would suggest to include ES 8 support if ES 8.6.0 is released anytime in the next 2-3 weeks. Otherwise we can retarget this upgrade to later versions of JanusGraph.

Notice, we have some issues targeting `1.0.0` release: https://github.com/JanusGraph/janusgraph/milestones/Release%20v1.0.0 
I don't think we will be able to complete all of them till the release but I guess some of them might be better to be included into the release.
Florian Grieskamp currently works on some features which may be a breaking change for all users but those features are quite good I think.
Cost based index selection: https://github.com/JanusGraph/janusgraph/pull/3246 
He is also working on re-engineering index management life-cycle which might be a breaking change as well (see issue: https://github.com/JanusGraph/janusgraph/issues/857) (see his branch: https://github.com/JanusGraph/janusgraph/compare/master...rngcntr:janusgraph:new-index-management).
I don't know if he plans to complete those issues anytime soon, but if he does then those contributions would be very suitable for the major release like `1.0.0`.

Regarding rc releases - I'm totally fine doing rc1, rc2, rcX. That said, I would suggest to maybe take a look at the following discussion again: https://lists.lfaidata.foundation/g/janusgraph-dev/topic/discussion_release_snapshot/84922650 
I still have some feeling that making snapshot (or whatever we call it) releases per each commit would make sense. Users will have an easy way to use all the latest JanusGraph features without waiting for official (fully tested) releases. 
With such approach I feel that official releases will be just an indicator to users that we tested the new added functionality which was added after the previous official release and we don't expect to break that functionality anytime soon.
Adding publishing to GitHub is quite easy (see an example: https://github.com/mapped/janusgraph/commit/a94a0c03cb9d1b1445901c6735aff3e66b8692ac ) but I think we could do that for sonatype as well if we think we need snapshots there.