Overall +1 On 26/07/2021 11:36, Garry Hurley wrote: > Yes, I kind of clicked send before my answer was finished because my > toddler was acting up next to me. What my position was is that the source > and any information related to 2.3.2 should be preserved
https://archive.apache.org/dist/james/server/ fit that role in my opinion. Also we can keep the SVN branches alive (maybe with a mention in the README as you state below). > but maybe add a > frame around the page or something, so that people know it is preserved for > posterity and not being supported. That frame should also include links to > the most up to date James source and so forth, along with a strong > encouragement to upgrade to the new version. +1 > > > On Sun, Jul 25, 2021 at 11:22 PM Rene Cordier <rcord...@apache.org> wrote: > >> Hello, >> >> I can understand some people are still running this version of James, >> it's never easy to migrate from a major version to an other. >> >> But community support... Even if the decision has not been taken >> officially (thus the discussion happening right now), do we still have >> that honestly? I don't think that any active developer on the James >> project right now ever worked on James before its version 3. So I hardly >> see how the current active dev team could potentially give support on it >> anyway at the moment. >> >> I find odd as well to have security concerns over centos and java >> versions for example, but not James. As Benoit said that version is >> likely full of CVEs and using dependencies that are not maintained >> anymore or the version used reached end of life support. >> >> A lot of efforts have been put in performance improvements as well in >> the latest versions of James too, and many more keep coming as we speak. >> >> If you guys knowing this still want to continue using James 2.3.2 >> because it is too much work to migrate or rewriting numerous custom >> mailets and modules well it is your choice for sure, and we respect >> that. However keep in mind that none of the active devs know the James >> v2 codebase (not that I know of). >> >> So except if you are ready to maintain it yourselves, I think we can >> officially declare we don't support it anymore. >> >> However it doesn't mean people still using it can't support between each >> other by using the ML or other means, right? :) >> >> Best regards, >> >> Rene. >> >> On 24/07/2021 22:38, Garry Hurley wrote: >>> I spent a lot of effort trying to migrate manually from 2.3.2 to 3.4.0 >> in a >>> project recently. It was a nightmare made necessary because the >>> organization did not allow any of the convenience mechanisms you guys >> built >>> into the new James 3 streams for migration. Additionally, the project >> used >>> a custom user interface that was dependant on the data structure of the >>> 2.3.2 database message repository. >>> On Fri, Jul 23, 2021 at 10:36 PM btell...@apache.org < >> btell...@apache.org> >>> wrote: >>> >>>> Hello Noel, >>>> >>>> First many thanks for your engagement that I believe did allow to have >>>> the amazing piece of software we have today. >>>> >>>> Apparently James 2.3 fails to talk SMTP with a modern Zimbra server, >>>> expects a 'dot' terminated stream. This 'bug' do not occur on modern >>>> James versions. >>>> >>>> Do we also maintain Apache Excalibur [1] ? Retired in 2010... As far as >>>> I get it, James 2.x actively relies on it. >>>> >>>> [1] https://excalibur.apache.org/ >>>> >>>> That, is one of many dependencies, to be fairly honest I would not be >>>> surprised a careful dependency audit finds hundreds of CVEs. Not to >>>> mention the use of outdated java versions. Given the effort, do we, as a >>>> community want to engage with serious maintenance of Apache James 2.3.x >>>> ? I have not seen security updates for years >>>> >>>> Also, new upcoming users are not fully aware of the state of that >>>> application, and might mistakenly believe they would get Apache grade >>>> quality (security, backed by an active community, etc...) >>>> >>>> In my opinion we should at the very least stops advertising that >>>> version, that means: >>>> >>>> - Archive related downloads >>>> - Remove references from the website >>>> >>>> That is our responsibility. >>>> >>>> Stating clearly as a community that we no longer assume maintining it >>>> would be better to me. >>>> >>>> Best regards, >>>> >>>> Benoit >>>> >>>> On 23/07/2021 23:10, Noel J. Bergman wrote: >>>>> I still use James v2 in production. I could be convinced to move >>>> forward (migration of config is a concern), but I still do run it, and >>>> would be able to fix any bugs, given the amount of code in there that >> was >>>> written by me. >>>>> Are there any particular defects that need to be addressed? I agree >>>> that it should be viewed as maintenance only, with no new development. >>>>> Oh, and hi! 😊 >>>>> >>>>> --- Noel >>>>> >>>>> -----Original Message----- >>>>> From: btell...@apache.org <btell...@apache.org> >>>>> Sent: Friday, July 23, 2021 5:18 >>>>> To: server-dev@james.apache.org >>>>> Subject: End of support for Apache James 2.3.2 ? >>>>> >>>>> Hello, >>>>> >>>>> Following recent discussions on gitter, issues are reported on Apache >>>> James version 2.3.2. >>>>> This version is not under active development (released in 2013 with a >>>> security fix in 2015 version 2.3.2.1). >>>>> No active development had been undertook recently. >>>>> >>>>> The source code is not available on Git / Github. >>>>> >>>>> I fear no real active committer is able to fix issues on it. >>>>> >>>>> It uses Avalon Phoenix retired in 2004 (yes...). >>>>> >>>>> For archeologists, sources can be found at >>>> http://svn.apache.org/repos/asf/james/server/tags/2_3_2_1/ >>>>> As such I propose to: >>>>> >>>>> - Make it clear with a formal vote we can refer to that the Apache >>>> James PMC no longer supports Apache James vers 2.x. >>>>> - Archive related downloads >>>>> - Remove references from the website >>>>> - Write a little email to the Apache announce mailing list, >>>> general@james, server-user@james. >>>>> Thoughts? >>>>> >>>>> Regards, >>>>> >>>>> Benoit TELLIER >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
