Le 31/08/2020 à 09:43, David Leangen a écrit : >>> From my point of view the most important point is to describe what >>> James does now. >> +1 > Yes, I agree. > > Again, I do not disagree that this is “most important”. Let me use a more > concrete example to illustrate why it is not the **only** concern. > > When I first looked into James, there was a complex grid to choose from > between Spring and Guice. Based on the grid, it seemed to me that Spring was > better. > > When I started asking questions, though, I understood that Spring is not > really being maintained anymore, or at least, more energy is being put into > Guice. > > Well, for me as a user trying to understand what to do, that is pretty darn > important information! I **WANT** to know where the project is heading, > because I need to be able to make decisions. So not only do I need to know > what the project’s vision is (which IMO needs a lot of clarification > currently), I need to know more concretely what the plans are for at least > the next major release. Else, how can I decide if it’s worth investing or not?
Well from what I recall, we had a nice community meeting answering that very question. - We will rework product definition, boundaries and branding. Using guice servers we will provide a basic/advanced/distributed server - We will improve the build experience through Apache CI builds and migrating to graddle. - Also, some contributors are implementing the final RFC-8621 JMAP release. Maybe we should have a roadmap page somewhere so that people don't have to read the DEV mailing list to find these pieces of information? > On that note, I would propose that for the 4.0 release, we clearly indicate > that Spring will **NOT** be available. +1, and a 4.0 would make the switch very clear. No ambiguity. I believe the only work remaining toward this is https://github.com/apache/james-project/pull/221 (and for other guice servers) > It should be deprecated in an upcoming 3.x release, then “completely” > eliminated in 4.0. (Perhaps some code could remain if some people really want > it, but we need to make it clear in the “user contract" that it is not > supported.) That would be precisely what a major release is for, IMO. We discussed (can't find the thread though) some years ago about the adoption of time based release for James server. This ensures we keep delivering improvement and fixing bugs even if we struggle delivering some major changes. Here we could maybe: - Better communicate about the release calendar (why not having it on the roadmap page?) - Prior the release date, discuss the reach of this release (major vs minor) and see how we are regarding roadmap items. - Also, the release process needs to be run faster... Would it answer some of your concerns? Benoit --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
