Hello, I realise this might seem controversial, and indeed this question has come up from time to time, but this time I will ask it and give proposals; the question is:
When will FVWM 2.5.X go stable? If one looks in the docs/ directory in the FVWM CVS repository, there's all manner of TODO lists and disjointed ideas without any structure -- that's fine, and in fact some of the items therein are already present in the current 2.5.X tree, so I suppose I ought to go through and consolidate and clean up those items already done. Is there a concrete roadmap for transitioning the current unstable branch of FVWM to stable, and effectively deprecating FVWM 2.4.X? I appreciate that's a bold step, even with the current state that 2.5.X is in, but note that: - Almost everyone I have advised over the years, I have suggested they use 2.5.X, without any ill-effects. - 2.5.X has many "modern" features in other WMs, namely: Colorsets, EWMH, etc. - 2.5.X has the concept of the Test command, deprecating InitFunction (which one still has to use when using 2.4.X), not to mention FvwmTheme still. For many many years, the manpage has several commands on deprecation (AddToDecor and friends being an obvious example). There is no way in hell that we can ever change this in 2.5.X without introducing significant syntax changes for .fvwm2rc. The same goes for any further expansion on things like Style commands (InitWindowStyle, separation of style matching to use name/class/resource cumulatively, etc.) We might as well cut our losses and admit these changes just won't get done now, but will in the future. Hence, I propose we brainstorm (and I do mean this) plans on what needs to be done for the current 2.5.X branch to mark it as stable, and, whilst we're doing it, those items we might want to actively work on in 2.7.X -- perhaps even with an eye to FVWM 3.0? I'm willing to do all the preliminaries, providing though such a step isn't a waste of my time -- i.e., I am happy to go through docs/ and consolidate some of the ideas in there removing those items that have already been done, as well as augmenting some of the documentation with newer ideas (such as the conversation Dominik and I had on window styles, per my InitialMapCommand patch series). If this is the sort of work that would make this viable, I'm up for it. Only at this rate, I can see us never releasing FVWM 2.5.X -- there has to be a point at which we say: "OK, it's a stable candidate", even if that means cutting our ideas short as a result. Thoughts? Suggestions? -- Thomas Adam
