On Mon, Oct 24, 2016 at 11:52:03PM +0100, Thomas Adam wrote: > On Mon, Oct 24, 2016 at 11:24:58PM +0100, Dominik Vogt wrote: > > How about a compromise: Leave the code in, but announce that > > these features are deprecated and will not be maintained anymore. > > So, if any people still use some of them (FvwmTheme, FvwmWinList, > > FvwmTaskBar and GNOME support being the most liekely), they can > > still use the code as it is. If any problems arise with these > > features, all we'll do is providing information on replacing the > > features. > > That's OK. I'm done with it anyway; I've put a lot of effort into dragging > FVWM out from its hiding place; improving it in the best way I could. I'm > actually proud to leave it in the state that's in in now---in the last six > months of effort I've spent putting into this, I've yet to have anyone tell me > that they'd miss these things, or that they're actually used.
Really, this is not about people who are interested in new fvwm development or who are simply content with what fvwm2 does now. It's only a service for people running obscure boxes with configurations maybe a ten years old kiosk system config who need an important fix. > But maybe you know different, in which case you're more than free to go ahead > with this > ---but know that I find it rather insulting to think that my efforts > have been largely ignored on the idea that the small minority of users might > be inconvenienced by these changes. Your efforts are *not* ignored. All these removals are good; the only thing I fell a bit uneasy about is removing GNOME support because I've seen so many funny commercial applications that use wild sets of GNOME/ICCCM2/EWMH hints, and these are notorius to be still broken ten years after a bug was found. > I just don't think that's true at all. > Trying to rearrange things is madness---and I won't have master rebased > because of that. That's not how this works, and I'm not hearing a good reason > for this at all. Actually, another way is to make an fvwm2-stable branch from 2.6.6 and backport the fixes from master. That's not much of an effort either, only that the ChangeLog entries will be missing for some of them. > If we're leaving 2.6 behind, we should do that by releasing master as 2.6.7 > and calling it a day. If people want something so badly, then they can use > 2.6.6 and do whatever ontop of it. Okay, then how about this: 1. Start a branch fvwm2-stable at 2.6.6 and document it as the long term stable branch. 2. Backport fixes and functional changes from master. 3. Release 2.6.7 on this branch with a proper announcement. 4. Release 2.9.0* on master and announce it as the release starting future development towards fvwm3. I can take care of 1 and 2 but need some help with 3 because I've never done a release using the new infrastructure. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
