Hi Oleksandr,

automating the release process or at least parts of it would definitely be great!

Right now, we have all issues and PRs closed that are linked to the milestone for 0.6.1 so we could in general proceed with the release process, but I think it wouldn’t be a big problem if we’d delay the release a bit so we could already use an automated release process.

Do you think that it makes sense to wait with the 0.6.1 release for this? Would it maybe even help if you could try out some of the automation directly during the release process? Or would this delay the release too much?

Hi,

I'm in favor of releasing 0.6.1 version. That said, it would make sense to automate the releasing process as Jan mentioned.
I'm planning to try to work on automation or partial automation this week. The main reason for that is to have deterministic way of making those builds.
At this moment when we are creating `jar`s which we are publishing everywhere - we are creating it locally on a release manager's computer with their own `java` installation.
Yes, the release manager signs every resource but we have no idea what version of Java was used to create this build. In theory if the release manager have vulnerable machine it could lead to infecting that `jar` with malicious code.
I think, it would be better to make all the builds in GH actions and use only them for release artifacts. 
I will try to work on that this week but I'm good if you release 0.6.1 using the current release process. Just use openjdk 1.8.<latest> for the release.

Best regards,
Oleksandr

Given that there haven’t been any responses, I assume that there are no major objections to releasing 0.6.1 soon but that there is also no high interest in getting it out as a hotfix release as soon as possible (which is OK in my opinion given that probably not many users are using the janusgraph.sh script to start JG+Cassandra+ES all at once).

So, I suggest that we just treat it as a normal maintenance release that will also contain the workaround for the Log4j CVE in ES among other fixes.

Are there any open issues / PRs that you think should be included in 0.6.1?

PR #2899 is already linked to the milestone v0.6.1 and it fixes a NullPointerException so I’d at least wait for that PR to be merged for 0.6.1: https://github.com/JanusGraph/janusgraph/pull/2899

Does anyone want to volunteer to be release manager for this release? Otherwise, I can also do it.

Hi,

we wanted to release patch versions shortly given the CVE in Log4j to mitigate it in the Elasticsearch version we distribute with the pre-packaged distribution: https://lists.lfaidata.foundation/g/janusgraph-dev/message/1554

I just merged a PR to the v0.6 branch with a simple mitigation: https://github.com/JanusGraph/janusgraph/pull/2892

As I explained in a comment in that PR, the mitigation now only landed in v0.6 and not in v0.5 as we don’t have any continuous integration for that branch and in general, I’m not sure it’s worth the effort to release a patch release for that branch, given that it only helps users who start JanusGraph together with ES from the `bin/janusgraph.sh` script.

So, we could release 0.6.1 now with the simple mitigation for ES. But if we want to release soon, then the release date would be in the middle of the holiday season. That would at least open the question whether someone is available over the holiday period to handle the release.

Since I will not be available myself, I personally suggest that we postpone the release to the beginning of January. If, however someone is willing to act as release manager during the holiday period, then we can still do the release soon. We would of course also need at least 3 TSC members for the VOTE, but I guess that should be possible if we could start the VOTE already in the beginning of next week.

Apart from the release date and who will be the release manager, are there any important issues still open that really need to be fixed for 0.6.1?

I think we should try to release 0.6.1 as soon as possible so new users don’t start with a vulnerable Elasticsearch installation and we can release 0.6.2 soon after, if necessary, but if you see any issues that we should really include, then we can discuss that of course.

Other questions that we could discuss for this release:

• Should we also update Elasticsearch from 7.14.0 to 7.16.1 (the version that includes the JVM property as a mitigation already and some more changes as precautions [1]) for the 0.6.1 release? Note that this would mean that users of the pre-packaged distribution would then start version 7.16.1 with already existing data created by 7.14.0. The ES release notes mention no breaking changes, but I’m still not sure whether we want to do that.
• Is everybody OK with only releasing a patch for 0.6, but not for 0.5, given my reasoning from a above (or a bit more detailed in the PR [2])?

Best regards,

Florian

[1]: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476#elasticsearch-4

[2]: https://github.com/JanusGraph/janusgraph/pull/2892#issuecomment-993536460

Hi,

we wanted to release patch versions shortly given the CVE in Log4j to mitigate it in the Elasticsearch version we distribute with the pre-packaged distribution: https://lists.lfaidata.foundation/g/janusgraph-dev/message/1554

I just merged a PR to the v0.6 branch with a simple mitigation: https://github.com/JanusGraph/janusgraph/pull/2892

As I explained in a comment in that PR, the mitigation now only landed in v0.6 and not in v0.5 as we don’t have any continuous integration for that branch and in general, I’m not sure it’s worth the effort to release a patch release for that branch, given that it only helps users who start JanusGraph together with ES from the `bin/janusgraph.sh` script.

So, we could release 0.6.1 now with the simple mitigation for ES. But if we want to release soon, then the release date would be in the middle of the holiday season. That would at least open the question whether someone is available over the holiday period to handle the release.

Since I will not be available myself, I personally suggest that we postpone the release to the beginning of January. If, however someone is willing to act as release manager during the holiday period, then we can still do the release soon. We would of course also need at least 3 TSC members for the VOTE, but I guess that should be possible if we could start the VOTE already in the beginning of next week.

Apart from the release date and who will be the release manager, are there any important issues still open that really need to be fixed for 0.6.1?

I think we should try to release 0.6.1 as soon as possible so new users don’t start with a vulnerable Elasticsearch installation and we can release 0.6.2 soon after, if necessary, but if you see any issues that we should really include, then we can discuss that of course.

Other questions that we could discuss for this release:

• Should we also update Elasticsearch from 7.14.0 to 7.16.1 (the version that includes the JVM property as a mitigation already and some more changes as precautions [1]) for the 0.6.1 release? Note that this would mean that users of the pre-packaged distribution would then start version 7.16.1 with already existing data created by 7.14.0. The ES release notes mention no breaking changes, but I’m still not sure whether we want to do that.
• Is everybody OK with only releasing a patch for 0.6, but not for 0.5, given my reasoning from a above (or a bit more detailed in the PR [2])?

Best regards,

Florian

[1]: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476#elasticsearch-4

[2]: https://github.com/JanusGraph/janusgraph/pull/2892#issuecomment-993536460