Hi Matthieu, I think that the cut should be done on the later the 15/03, yes.
Regards, Benoit Le 02/03/2021 à 20:36, Matthieu Baechler a écrit : > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
