A big thread, let's jump in. Le 28/09/2020 à 02:34, Matthieu Baechler a écrit : > Hi, > > I'm not sure which message to answer in the thread so I start a new > thread to summarize my thoughts on the various topics discussed. > > 1. About Roadmap > > [...] > > 2. About documentation > > [...] > > TL;DR we have to explain how it already works +1 > > 3. About versioning (3.x vs 4.0) > > Like roadmaps, major version numbers give people expectations: there > must be something very new and/or very different because the > community decided to increment major version number. > > Last time the community tried that (3.0) the projects almost died > because too many things had to ship at the same time and then was > never ready. It took years to finally release it after Linagora > started to invest a lot it and by the way, we never finished what > was supposed to, we just decided that, no software being perfect, we > had to release this much-better-than-2.x version. > > I would like to take the Linux Kernel path: > > * only increment minor version for the time being > * don't build a backlog or any list of things we want to achieve > before incrementing > * release 2 to 4 times a years with what is ready > * increment major version when what will be ready deserves it or > when minor number get to big Spring deprecation could be seen as this big event for most users ? > 4. About defining a vision > > [...] > > What I would really like is to break things! Let's remove all > these anachronic modules, or even better: let's build James 4 by > adopting only well selected modules, ones that are here for a purpose. I do think that such an effort will end up with similar effects for the community than the 3.0 release effort.
What I am looking for is a scalable, modern mail server, we mostly have that already (after 5 years of development which is already a huge commitment). Note that I am also convinced that we need better documentation, and that we need to simplify the project structure. With my Linagora hat on now, I see no way to convince my management to dedicate any effort toward a completely reworked 4.0 with a several years ETA. > > People could either jump to this fresh version of James or keep > maintaining the 3.x branch. If they lack some modules that were not > selected for James 4, they could just port these modules to the new > APIs. > > By doing such a move, we could focus to finally solve our longstanding > problems like: developer experience, newcomers welcoming, having a > decent and up-to-date documentation, very easy first deployment, etc. > > What would you think of such a move ? I would prefer a more pragmatic alternative. We as a community could be identifying features / modules that should not have made it in the 3.x release line. We could decide to deprecate then remove these modules, hopefully letting time for third party to backport alternatives. As such we would end up with a much simpler code base. The downside is that core API stability would be (to some extent) needed. > > 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
