Hi Juhan, On Tue, 2021-03-02 at 11:10 +0200, Juhan Aasaru wrote:
[...] > I think (sadly) ElasticSearch V7 migration (and ES V6 backport) will not > be ready on time for this release, unless additional efforts are > committed to this issue. Since James guice version currently uses Elasticsearch 6.x that has reached end of life and our system cannot go live with old Elasticsearch then we would be very interested in getting this upgrade into a release (preferably into 3.6.0) and put in work in this. I know my colleague Andreas has made an effort to add Elasticsearch 7 support in James and as I understand it currently the problem is to get all the tests to pass in Elasticsearch 7 related modules. But it is unclear to me what is the plan to continue supporting Elasticsearch 6 in parallel. We probably won't be able to support both versions in the same product for a reasonable cost so I propose to drop ElasticSearch 6 support entirely. Would it be possible to have a quick recap of the remaining efforts needed. One place for this could be the Jira task: https://issues.apache.org/jira/browse/JAMES-3492 If the work required to finish is not too large I could get Andreas to come back and work on this starting this Friday. Hopefully this way we have a chance to reach the release deadline (or at least have a second release shortly after the current on) Let's define a deadline. That way, rather it's ready on time and included or not. If you need some help to make it happen, you may find some people offering consulting, we are several to be able to do that on the mailing-list. > the last release taking me over 3 months! Benoit, could you please list the main problems why creating a release is time consuming so we could think solutions how some of this could be automated. For example if PGP signing and publishing artifacts to Maven Central is time consuming then this could be automated in great deal. I created a JIRA issue for this automation initiative: https://issues.apache.org/jira/browse/JAMES-3510 Thanks, good idea. Regarding a release I have planned to raise a new topic that we as a community could think about a "long-term-support" release of James. Currently any James release is more like just a point in time marker but probably many of us have a vision that for a release we could create a separate branch and later only merge important security fixes there and then we could release patched versions like 3.6.1, 3.6.2 etc coming out in parallel with new main releases 3.7.0, 3.8.0 etc I'm interested in getting this set up and working on getting the patches identified and released but for this we would need to dramatically shorten the time and effort it takes to create a (minor/major) release. So this is why I would come back to "long-term-support-version" a bit later. If you want to handle that burden, that's awesome. I think nobody would be against having and LTS release for James. Cheers, -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
