Hi,

We currently maintain the JanusGraph Docker images in their own repository: https://github.com/JanusGraph/janusgraph-docker

While this comes with some benefits, like making it probably easier for new contributors to contribute to the images as the build process is easier to understand with only having the images there, it also comes with some drawbacks:

• After every release, we also have to perform a release in the docker repo.
• We don’t know whether a change in the main repo breaks the images until after a release as the Docker images won’t get a change before that.
• Config in the main repo sometimes also need to be performed for the config in the image repo which we can easily forget. (Example: janusgraph/janusgraph-docker#113)

Recently, we noticed another problem caused by having a dedicated repo for the Docker images: Security scans don’t work well for the repo because the repo also contains images for all release branches and shows alerts for all images together and because alerts oftentimes have to be addressed in the main repo by updating a dependency there. For more information, see: https://github.com/JanusGraph/janusgraph-docker/issues/130

That is why Jan suggested in the linked issue that we integrate the Docker image into the main repo. Does anyone see good reasons to keep the dedicated janusgraph-docker repo?

If not, then we can move ahead and integrate the Docker images into the main repository. The 0.6 image would then be maintained in the v0.6 branch and the 1.0 image on master.

I checked the links, and everything looks good to me.

VOTE +1

We are happy to announce that JanusGraph 0.6.3 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.6.3

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.3/janusgraph-full-0.6.3.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/blob/v0.6/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.3/janusgraph-0.6.3-doc.zip

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.6.3

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.6/docs/changelog.md#version-063-release-date-february-18-2023

This [VOTE] will open for the next 3 days --- closing Thursday, February 23, 2023 at 10:15 PM GMT+0.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.

Thank you,
Oleksandr Porunov

Hi,

in case you haven’t noticed already: We have recently changed our branching strategy. Instead of letting PRs target a branch like v0.6 and then merge the PR first into v0.6 and afterwards merge v0.6 into master, we now use a backporting approach.

This means that all PRs should in general target master. We can then decide if the change should be backported and then add the right label to enable automatic backporting (currently: `backport/v0.6`).

There are of course exceptions, e.g., if a PR fixes a bug in code that is only present on v0.6 but not on master. In that case, the PR can simply target v0.6 and also doesn’t have to be merged into master.

The backport approach should make it easier for first-time contributors who usually just start from master which oftentimes meant in the past that we had to ask them to retarget their PR on a different branch.

We have also documented this automatic backporting here: https://docs.janusgraph.org/master/development/#enable-automatic-backporting

For all committers: Please make sure that you follow this backporting strategy and don’t merge v0.6 into master anymore.

Regards,

Florian

Thanks, Oleksandr. I saw that PR when I composed the list but thought that #3022 already included the important changes. But sure, then we should also include #3327 for the next announcement.

Also, it looks like the formatting is off in my announcement. I copied some parts of the changelog from the discussion thread we had here on the dev list and then probably forgot to change their formatting. Sorry for that!

Thank you Florian for starting this topic.

For future announcements:

In addition to possibility to remove composite index entries there was added possibility to remove mixed index entries in #3327
So I guess instead of the next point:
Add possibility to remove stale composite index entries: #3022
We could have the next point
Add possibility to remove stale graph index entries: #3022 and #3327

The JanusGraph Technical Steering Committee is excited to announce JanusGraph 1.0.0 RC1, the first release candidate of the upcoming 1.0.0 release.

JanusGraph is an Apache TinkerPop enabled property graph database with support for a variety of storage and indexing backends. Thank you to all of the contributors.

We encourage everyone to try out this release candidate in your test environments and provide us feedback. You can simply reply to this thread with any feedback you have. Note that this is a release candidate and not a final release. Some changes should be expected between this and the final release of 1.0.0.

Notable new features in this release include:

• Upgrade to TinkerPop 3.6.1: #3208
• Support for Cassandra 4: #2325
• (Official) support for Java 11: #2161
• Cache performance improvements: #3185 and #871
• Upgrade to Log4j2: #2890
• Use mixed indices for numeric aggregations (min(), max(), mean(), sum()): #3202
• Support TEXTSTRING mapping in Solr: #328
• New graph API to evaluate Gremlin scripts if JanusGraph is used embedded: #3149
• ConfiguredGraphFactory can now create different indexes for different graphs in Elasticsearch: #3338
• Add management API to remove ghost vertices: #2910
• Add possibility to remove stale composite index entries: #3022
• Improved support for Geoshapes in GraphBinary: #2856
• Remove dependency on cassandra-all: #3245
• Support TTL for CQL backend on Amazon Managed KeySpace: #3325
• Lots of updates for other dependencies

The release artifacts can be found at this location:
    https://github.com/JanusGraph/janusgraph/releases/tag/v1.0.0-rc1

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v1.0.0-rc1/janusgraph-full-1.0.0-rc1.zip

A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v1.0.0-rc1/janusgraph1.0.0-rc1.zip

The online docs can be found here:
    https://docs.janusgraph.org/master/

The resolved issues and commits included in this release candidate can be found here:

    https://github.com/JanusGraph/janusgraph/pulls?q=closed%3A%3C2022-12-08+milestone%3A%22Release+v1.0.0%22

Thank you very much,

Florian Hockmann

Thanks for bumping this thread again in the discussion for the 1.0.0 release, Oleksandr!

> Basically, I think it's possible to configure different publishing flows (either to sonatype for official releases or to GitHub Packages for unofficial releases).

+1 on GitHub Packages for snapshots on each commit and sonatype for official releases.

As a possible next step for the future, we could maybe also build a Docker image for each commit (or daily if it’s difficult to trigger a build in janusgraph-docker from each commit in the main repo) and publish that somewhere (not sure if Docker Hub or also a different repo for these non-release based images).

> Moreover, about the link which you shared. Did we document it anywhere? If no, I think it would be good to create a separate documentation page which tells about release artifacts for each commit and potentially releases to GitHub Packages for each commit. 

No, that is not documented any where that I know of. I at least searched for these artifacts recently but couldn’t find them. Documenting this would be great, especially of course if we also publish Maven snapshot packages to make them easier to consume.

One general note: I would usually just assume lazy consensus for such discussions where you don’t get many responses and especially no negative response. People here simply might not have the time to respond, but that doesn’t mean that they don’t like the idea. I remember that I’ve read this thread, liked the idea, but didn’t have much to add to the discussion so I didn’t respond. Such a behaviour shouldn’t stop good ideas from being implemented 😉

Hi Jan,

Thanks for pointing on that! That indeed uploads distribution for a commit but it doesn't provide you with the maven nexus repository to use those distributions. Basically, it means, that you will need to physically download `distribution-builds` and run it. In case you would like to run JanusGraph embedded into the application, it becomes not as easy to be used due to necessity to include transitive dependencies manually.
What I mean is to publish staging artifacts to the maven repository such as GitHub actions. If so, people could just include latest JanusGraph master snapshot releases simply defining something like:

Ignore `version` as for now because I didn't think about versioning yet but you can see a simple example here: https://github.com/orgs/mapped/packages?repo_name=janusgraph
See the commit here: https://github.com/mapped/janusgraph/commit/a94a0c03cb9d1b1445901c6735aff3e66b8692ac

Basically, I think it's possible to configure different publishing flows (either to sonatype for official releases or to GitHub Packages for unofficial releases).

Moreover, about the link which you shared. Did we document it anywhere? If no, I think it would be good to create a separate documentation page which tells about release artifacts for each commit and potentially releases to GitHub Packages for each commit.  

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.