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.