On Tue, 2020-09-29 at 08:59 +0700, Tellier Benoit wrote: [...]
> Spring deprecation could be seen as this big event for most users ? You are not very good at public relation, do you? (: I don't see feature deprecation as a good opportunity to increment major version number. > > 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. I agree to some extent. > 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). I know that it's Linagora intent. However, you are still slow to reach that goal partly because of James codebase size. Also, you will keep having a clutered product that most people won't see as a "scalable, modern mail server". > 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. I think you disagreement is mainly about what you assume 4.0 would be. Let's dig this topic. A plan could be: 1. create a 3.99 branch which would be a new James-from-scratch project 2. define progressive goals to implement 3. progressively import modules to 3.99 following defined goals, breaking as many things as we want to simplify the project 4. release 3.99.x versions along the way with no guarantee about API and operation stability 5. as 3.99 reach a product we like and want to support, switch from 3.99 to 4.0 3.0 was stuck in alpha/beta stage for years. People started using it by forking it or using a fixed snapshot. Given the work left to release the 3.0, nobody care enough because they had a working project locally. By the way, 3.0 wanted to keep API stability on some topics while at the same time never provided any decent upgrade path. Now our components are basically working: we don't have to write much things to build this 3.99, we have to combine things and get rid of the weight preventing us to have a leaner product. If it takes years, it's because there's no workforce on it, not because it's a huge work. The good thing about this strategy is: we can go ahead with 3.x branch at the same time and can drop this 3.99 strategy at any point if we conclude it's a dead end. What Linagora wants or not is not relevant in this case. > > 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. How it is different from what we did for years? Did it solve velocity issues? Is the project fun now? I may start this 3.99 thing on my fork to see how it goes and will keep you posted about that. Cheers, -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
