Hi Matthieu, Hi Juhan, Le 02/03/2021 à 20:36, Matthieu Baechler a écrit : > Hi Juhan, > > On Tue, 2021-03-02 at 11:10 +0200, Juhan Aasaru wrote: > > [...] > > 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.
+1 > > 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. +1 > 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. - First, previous release had been rejected once. And one time where we struggle to get the approval on time. - Second, the numerous maven project counts makes the upload (mvn deploy / mvn release prepare / perform) long. I generally plan a day, and do it on my laptop not to copy my GPG keys around. Which negatively impact my other tasks. To be fair, this one should be less of a problem to me this time. - Third: changing priorities... > 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: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
