On Fri, 11 Nov 2016 23:13:49 +
Thomas Adam 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
