On Fri, 11 Nov 2016 23:13:49 +0000 Thomas Adam <tho...@fvwm.org> wrote:
> Hello all, > > For those of you who follow fvwm-workers@ may already know some of > this, but for those of you who don't, it's worth mentioning what the > state of fvwm development holds for the future. > > We have been discussing a lot about how we're able to make changes to > fvwm without breaking it for everyone. As many will know doubt know, > fvwm is well-over twenty years old and in some cases it shows, too! > Trying to bring fvwm up to date with newer technologies, and to even > make small improvements has a very high barrier to entry, especially > when trying to maintain backwards compatibility. Over the years, we've > had a loyal number of users who have come to rely on a lot of nuances > and behaviour which we don't necessarily want to take away. > > To that end, the latest stable release (2.6.7) marks the end of the > line for fvwm2. This release is unique because it was my opportunity > to remove all of the modules which I thought were no longer providing > anything useful (because the functionality no longer exists outside of > fvwm in certain applications, or because more widely-used modules in > fvwm provided equivalent/better funtionality). Indeed, this releases > also includes a new default configuration. I hope you find it useful. > > But I suppose it's fair to say that 2.6.7 won't necessarily appeal to > some of the dyed-in-the-wool types for whom changes is too much, and/or > cannot live with that really old module which works Just Fine (tm) as > it is. Well, that's OK as well, since we also have everything as it > was before on the 'fvwm2-stable' branch. So if you want to use things > like FvwmTaskBar, for example, that's the release you should use. This > branch may, occasionally, receive bug-fixes over time, but certainly > nothing else. > > In fact, I'm not envisaging any further work happening on fvwm2.X at > all. So what does this mean for fvwm? In order for us to continue to > make larger changes, we need to be able to break backwards > compatibility and to make a lot of structural changes. All of this > goes towards a lot of other changes we'd like to make. This therefore > means that we will look at fvwm3 to do this. This will be different to > fvwm2. > > We're in the process of setting up fvwm3, and there'll be additional > announcements when this is complete. > > For a reference on the releases, see the following: > > https://github.com/fvwmorg/fvwm#releases > > Any questions, do please ask. > > Kindly, > Thomas Adam > Not so much a question as a comment. Many window managers and desktop environments have tried in vain to create an automatic menu generator without success, I recommend that fvwm does not attempt to do this, they break very easily over time. Also, please retain the win95 configuration script, in fact, they ability to run a simple script to generate a few different common configurations is a strong point of many WMs. Thanks, David