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, 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.
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 > >
