Re: Final long term stable version
On Fri, Nov 11, 2016 at 11:35:42AM +, Thomas Adam wrote: > On Wed, Nov 09, 2016 at 09:01:20PM +, Thomas Adam wrote: > > On Tue, Oct 25, 2016 at 01:26:19AM +0100, Dominik Vogt wrote: > > > The branch dv/stable-fvwm2 is up for review. Collecting the > > > patches was a piece of cake. Just one conflict with the NEWS > > > file. The branch builds fine for me, without warnings, and I'm > > > using it now for work. > > > > Indeed -- it seems fine for me too. We should ideally rename this as > > 'fvwm2-stable'; I can do that if you don't have time, but I'm certainly > > happy > > to call this complete and releasable -- with the appropriate documentation > > updated, too. > > Branch pushed; documentation to follow. Thanks. I'm still hoping that crash shows up again soon so that it can be fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Wed, Nov 09, 2016 at 09:01:20PM +, Thomas Adam wrote: > On Tue, Oct 25, 2016 at 01:26:19AM +0100, Dominik Vogt wrote: > > The branch dv/stable-fvwm2 is up for review. Collecting the > > patches was a piece of cake. Just one conflict with the NEWS > > file. The branch builds fine for me, without warnings, and I'm > > using it now for work. > > Indeed -- it seems fine for me too. We should ideally rename this as > 'fvwm2-stable'; I can do that if you don't have time, but I'm certainly happy > to call this complete and releasable -- with the appropriate documentation > updated, too. Branch pushed; documentation to follow. -- Thomas Adam
Re: Final long term stable version
On Tue, Oct 25, 2016 at 01:26:19AM +0100, Dominik Vogt wrote: > The branch dv/stable-fvwm2 is up for review. Collecting the > patches was a piece of cake. Just one conflict with the NEWS > file. The branch builds fine for me, without warnings, and I'm > using it now for work. Indeed -- it seems fine for me too. We should ideally rename this as 'fvwm2-stable'; I can do that if you don't have time, but I'm certainly happy to call this complete and releasable -- with the appropriate documentation updated, too. -- Thomas Adam
Re: Final long term stable version
On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be > the last stable/supported version. Up to this point I've installed all > optional libraries and fixed all the warnings for the versions I have > available (FreeBSD) -- so that's something. I think it's in a good state to > be left behind, and allowing it to receive minor fixes, etc. So, fvwm now has the default configuration file merged into master. It's undergone quite a bit of testing, along with the fvwm-menu-desktop changes (which I'm not as fussed by). But this now means we can cut a release for 2.6.7, and start thinking about how we announce this, along with fvwm3. -- Thomas Adam
Re: Final long term stable version
On Tue, Oct 25, 2016 at 02:01:04AM +0100, Dominik Vogt wrote: > That leaves much room for interpretation. A "clean break" to me > would mean to write it from scratch, and that's practically > impossible because the fvwm2 window managing code contains many > hundreds of hours undocumented experience with strange > applications and optimising communication with the X server. Sorry -- I'm not suggesting it's from scratch, but I really want to ensure that by "clean break", I mean an opportunity to not be hindered, and for us to adopt more "current" things such as XCB. I see that as a real benefit. Consistency is another thing I'd like to see. > I have no intention of removing _useful_ features because the code > looks ugly. No one has suggested that. -- Thomas Adam
Re: Final long term stable version
On Tue, Oct 25, 2016 at 01:38:17AM +0100, Thomas Adam wrote: > On Tue, Oct 25, 2016 at 01:08:21AM +0100, Dominik Vogt wrote: > > > I wouldn't bother with this point---fvwm3 should be a separate repository > > > entirely. > > > > Why? Unless some people step up and tell us they'd want to take > > over fvwm2 development, what is the gain of duplicating all > > infrastructure? > > You're assuming fvwm3 is based off fvwm2 for anything. Whilst that might be > true for somethings, I think that should be the exception rather than the > rule. I was serious in my proposal to make fvwm3 a clean break, and it should > be that in its entirety including its own repository. That leaves much room for interpretation. A "clean break" to me would mean to write it from scratch, and that's practically impossible because the fvwm2 window managing code contains many hundreds of hours undocumented experience with strange applications and optimising communication with the X server. Well, my plan for fvwm3 has always been to make changes to fvwm2 to be able to do things that are not possible with todays code. For example, styles that can be attached to window states or even more complex conditions. One thing that gets in the way of lots of future work is the terrible parser and backwards compatibility of the syntax. I also want to see FvwmButtons being replaced by something flexible, configurable at run time and useable. I have no intention of removing _useful_ features because the code looks ugly. > I question what "infrastructure" might be needed from fvwm2 that would mean > using it as a basis. Developers, repository, webspace. > > That would be good (I'm assuming that you mean just #3). Give me > > some time to organise the fvwm2-stable branch (suggestions for a > > better name welcome maybe "stable-fvwm2"). > > Yes, I was just referring to point #3; let me know when that's good to be > done. As soon as we know that nothing important is missing from dv/stable-fvwm2. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Tue, Oct 25, 2016 at 01:08:21AM +0100, Dominik Vogt wrote: > > I wouldn't bother with this point---fvwm3 should be a separate repository > > entirely. > > Why? Unless some people step up and tell us they'd want to take > over fvwm2 development, what is the gain of duplicating all > infrastructure? You're assuming fvwm3 is based off fvwm2 for anything. Whilst that might be true for somethings, I think that should be the exception rather than the rule. I was serious in my proposal to make fvwm3 a clean break, and it should be that in its entirety including its own repository. I question what "infrastructure" might be needed from fvwm2 that would mean using it as a basis. That's not what I was thinking at all, but this clearly needs more discussion. But fvwm3 will be separate from fvwm2. > Well, at the moment the only interesting issue is how to name the > release tags. I'd prefer a naming scheme like 3.-1.x, but the > tools will probably not like this. :-) Have another look in DEVELOPERS.md; the next release should be tagged as 2.6.6-stable, then 2.6.7, etc. No more "version_x_y_z" from CVS, that's what the tooling really doesn't like. > > > 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. > > > > I can take care of that if you like? > > That would be good (I'm assuming that you mean just #3). Give me > some time to organise the fvwm2-stable branch (suggestions for a > better name welcome maybe "stable-fvwm2"). Yes, I was just referring to point #3; let me know when that's good to be done. -- Thomas Adam
Re: Final long term stable version
On Tue, Oct 25, 2016 at 01:08:21AM +0100, Dominik Vogt wrote: > On Tue, Oct 25, 2016 at 12:53:44AM +0100, Thomas Adam wrote: > > On Tue, Oct 25, 2016 at 12:48:01AM +0100, Dominik Vogt wrote: > > > Okay, then how about this: > > > > > > 1. Start a branch fvwm2-stable at 2.6.6 and document it as the > > >long term stable branch. > > > > OK. > > > > > 2. Backport fixes and functional changes from master. > > > > OK. (Which, and why?) > > Obviously at least the fix I've just made to FEvent.c as it was > introduced in 2.6.6 and breaks things really badly. The fix for > the hang in FvwmButtons is another likely candidate. There are > only a few interesting commits. Possibly the things you mentioned > in NEWS, which sound all like small changes. > > > > 3. Release 2.6.7 on this branch with a proper announcement. > > > > OK. > > > > > 4. Release 2.9.0* on master and announce it as the release > > >starting future development towards fvwm3. > > > > I wouldn't bother with this point---fvwm3 should be a separate repository > > entirely. > > Why? Unless some people step up and tell us they'd want to take > over fvwm2 development, what is the gain of duplicating all > infrastructure? > > Well, at the moment the only interesting issue is how to name the > release tags. I'd prefer a naming scheme like 3.-1.x, but the > tools will probably not like this. :-) > > > > 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. > > > > I can take care of that if you like? > > That would be good (I'm assuming that you mean just #3). Give me > some time to organise the fvwm2-stable branch (suggestions for a > better name welcome maybe "stable-fvwm2"). The branch dv/stable-fvwm2 is up for review. Collecting the patches was a piece of cake. Just one conflict with the NEWS file. The branch builds fine for me, without warnings, and I'm using it now for work. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Tue, Oct 25, 2016 at 12:53:44AM +0100, Thomas Adam wrote: > On Tue, Oct 25, 2016 at 12:48:01AM +0100, Dominik Vogt wrote: > > Okay, then how about this: > > > > 1. Start a branch fvwm2-stable at 2.6.6 and document it as the > >long term stable branch. > > OK. > > > 2. Backport fixes and functional changes from master. > > OK. (Which, and why?) Obviously at least the fix I've just made to FEvent.c as it was introduced in 2.6.6 and breaks things really badly. The fix for the hang in FvwmButtons is another likely candidate. There are only a few interesting commits. Possibly the things you mentioned in NEWS, which sound all like small changes. > > 3. Release 2.6.7 on this branch with a proper announcement. > > OK. > > > 4. Release 2.9.0* on master and announce it as the release > >starting future development towards fvwm3. > > I wouldn't bother with this point---fvwm3 should be a separate repository > entirely. Why? Unless some people step up and tell us they'd want to take over fvwm2 development, what is the gain of duplicating all infrastructure? Well, at the moment the only interesting issue is how to name the release tags. I'd prefer a naming scheme like 3.-1.x, but the tools will probably not like this. :-) > > 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. > > I can take care of that if you like? That would be good (I'm assuming that you mean just #3). Give me some time to organise the fvwm2-stable branch (suggestions for a better name welcome maybe "stable-fvwm2"). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
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
Re: Final long term stable version
On Sun, Oct 23, 2016 at 11:50:48AM +0100, Thomas Adam wrote: > On Sun, Oct 23, 2016 at 11:46:23AM +0100, Dominik Vogt wrote: > > The old stable branch should provide important fixes for people > > who use old versions, and that includes not taking away stuff from > > them, no? The idea is that people who have some good (but rare) > > reason to stick with the old version can continue doing so. > > > > > Given all of this, I think it's safe to do this. I have heard nothing > > > from > > > anyone in recent years who are using the above, and/or who haven't already > > > migrated to FvwmButtons or FvwmTaskbar for the most part. > > > > But actually these removals are only half a year old and are not > > part of any release yet. > > So this work is going towards that next release. If you were to forget about > 2.6.7 being the last release of fvwm2 before we move away to pastures new, > then this work is simply another iteration on improving fvwm2. This is where > I want to leave fvwm2, in a known good state, by removing all the things I've > mentioned. It means the user can actually use something which is "current", > and more maintainable, and it also means that any maintenance work needed is > reduced in scope because there's less things to worry about. 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. I understand your wish to leave fvwm2 in a clean, maintainable state but think that leaving it as compatible as possible is more important here so that people can keep using the feature set they are used to. Remember that we're not making the long term stable release to win a beaty contest but to make the transition for the users as painless as possible. Anyway, leaving the modules in won't cause anybody any pain. The only thing that is potentially problematic regarding maintenance is GNOME support (and removing it may be problematic too because there are (mostly commercial) applications out in the wild that still use it). After this one time cut were free to conclusively remove any old features and never look back. With just a little more work (a few hours), adding the removal patches right after the release is just a matter of glueing the release label to the right commit. Reshuffling the commits is quite easy (see dv/master-late-deletes branch), and the commit before the removal patches still builds fine. It's just a bit more work to figure out what to do with NEWS and INSTALL.fvwm. The only thing that's not nice is that the master needs to be rebased once. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Sun, Oct 23, 2016 at 11:46:23AM +0100, Dominik Vogt wrote: > The old stable branch should provide important fixes for people > who use old versions, and that includes not taking away stuff from > them, no? The idea is that people who have some good (but rare) > reason to stick with the old version can continue doing so. > > > Given all of this, I think it's safe to do this. I have heard nothing from > > anyone in recent years who are using the above, and/or who haven't already > > migrated to FvwmButtons or FvwmTaskbar for the most part. > > But actually these removals are only half a year old and are not > part of any release yet. So this work is going towards that next release. If you were to forget about 2.6.7 being the last release of fvwm2 before we move away to pastures new, then this work is simply another iteration on improving fvwm2. This is where I want to leave fvwm2, in a known good state, by removing all the things I've mentioned. It means the user can actually use something which is "current", and more maintainable, and it also means that any maintenance work needed is reduced in scope because there's less things to worry about. -- Thomas Adam
Re: Final long term stable version
On Sun, Oct 23, 2016 at 03:22:08AM +0100, Thomas Adam wrote: > On Sun, Oct 23, 2016 at 03:12:19AM +0100, Dominik Vogt wrote: > > On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > > > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > > > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will > > > be > > > the last stable/supported version. Up to this point I've installed all > > > optional libraries and fixed all the warnings for the versions I have > > > available (FreeBSD) -- so that's something. I think it's in a good state > > > to > > > be left behind, and allowing it to receive minor fixes, etc. > > > > Hm, is it actually a good idea to remove half the modules and > > GNOME hints support in the last stable fvwm2 release? Could the > > commits be rearranged so that this stuff stays in 2.6.7 and is > > removed immediately after that? > > > > Or maybe start the long term stable branch at 2.6.6 and > > cherry-pick only the patches that add something from master. > > Hmm. Why? I'm *not* against removal of anything on that list. It's just very inconsinstent if we announce "2.6.7 is the last long time stable version of fvwm2, and after that release we start rewriting stuff from scratch and remove old things" and then actually start removing things in 2.6.7. The old stable branch should provide important fixes for people who use old versions, and that includes not taking away stuff from them, no? The idea is that people who have some good (but rare) reason to stick with the old version can continue doing so. > Given all of this, I think it's safe to do this. I have heard nothing from > anyone in recent years who are using the above, and/or who haven't already > migrated to FvwmButtons or FvwmTaskbar for the most part. But actually these removals are only half a year old and are not part of any release yet. > As for GNOME hints support -- that's reduced code, and isn't used in the wild > at all. Good for me, I hate that code. > Should enough people complain loudly enough, sure, I might add it back in, but > I really don't think they will. So I still think going ahead with 2.6.7 in > this state--whereby we've made the best effort to leave it with *useful* stuff > that we then don't have to fix in the future, can only been a good thing. All I care is having a base for long term maintenance without breaking things. I'd even be fine to release 2.6.7 as the last old stable release without the removals and 2.7.0 adding them back on the same day. (But first this acroread issue needs to be resolved.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Sun, Oct 23, 2016 at 03:12:19AM +0100, Dominik Vogt wrote: > On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be > > the last stable/supported version. Up to this point I've installed all > > optional libraries and fixed all the warnings for the versions I have > > available (FreeBSD) -- so that's something. I think it's in a good state to > > be left behind, and allowing it to receive minor fixes, etc. > > Hm, is it actually a good idea to remove half the modules and > GNOME hints support in the last stable fvwm2 release? Could the > commits be rearranged so that this stuff stays in 2.6.7 and is > removed immediately after that? > > Or maybe start the long term stable branch at 2.6.6 and > cherry-pick only the patches that add something from master. Hmm. Why? I put this out for discussion ages ago. The modules I identified for removal were because: * They're broken: - FvwmSave - FvwmSaveDesk - FvwmDragWell - FvwmGTK * They're surpassed by other---more established modules---which people are * already using: - FvwmWharf -> FvwmButtons - FvwmTaskBar -> FvwmIconMan - FvwmWinList -> WindowList command and/or FvwmIconMan * They're old and/or were only ever written as a proof-of-concept: - FvwmScroll (nice, but...) - FvwmTabs - FvwmWindowMenu (WindowList command) Given all of this, I think it's safe to do this. I have heard nothing from anyone in recent years who are using the above, and/or who haven't already migrated to FvwmButtons or FvwmTaskbar for the most part. As for GNOME hints support -- that's reduced code, and isn't used in the wild at all. Should enough people complain loudly enough, sure, I might add it back in, but I really don't think they will. So I still think going ahead with 2.6.7 in this state--whereby we've made the best effort to leave it with *useful* stuff that we then don't have to fix in the future, can only been a good thing. -- Thomas Adam
Re: Final long term stable version
On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be > the last stable/supported version. Up to this point I've installed all > optional libraries and fixed all the warnings for the versions I have > available (FreeBSD) -- so that's something. I think it's in a good state to > be left behind, and allowing it to receive minor fixes, etc. Hm, is it actually a good idea to remove half the modules and GNOME hints support in the last stable fvwm2 release? Could the commits be rearranged so that this stuff stays in 2.6.7 and is removed immediately after that? Or maybe start the long term stable branch at 2.6.6 and cherry-pick only the patches that add something from master. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > On the back of the current TODO.md file, I'll draft a list of key-features as > I see them and send it out for review/discussion here. I've tentatively started a skeleton file to collate ideas. See the 'ta/next' branch in git, hence: https://github.com/fvwmorg/fvwm/blob/ta/next/FVWM3.md -- Thomas Adam
Re: Final long term stable version
On Sat, Oct 22, 2016 at 02:25:53PM +0100, Dominik Vogt wrote: > On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > > > * From version X+1 onwards, no guarantees are made about > > >continued support of obscure features, until there's an > > >official fvwm-3.0. > > > > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be > > the last stable/supported version. Up to this point I've installed all > > optional libraries and fixed all the warnings for the versions I have > > available (FreeBSD) -- so that's something. I think it's in a good state to > > be left behind, and allowing it to receive minor fixes, etc. > > I'm fixing the warnings I discovered through building with all > configurable features switched off. The result should probably > make it into 2.6.7. Cool -- I'll wait until that happens then. Thanks. -- Thomas Adam
Re: Final long term stable version
On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > > * From version X+1 onwards, no guarantees are made about > >continued support of obscure features, until there's an > >official fvwm-3.0. > > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be > the last stable/supported version. Up to this point I've installed all > optional libraries and fixed all the warnings for the versions I have > available (FreeBSD) -- so that's something. I think it's in a good state to > be left behind, and allowing it to receive minor fixes, etc. I'm fixing the warnings I discovered through building with all configurable features switched off. The result should probably make it into 2.6.7. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > While the enthusiasm to remove outdated stuff (strokes, Xinerama, > colourmaps, old parser etc.) is an important step towards a > maintainable and nice future fvwm3, there are certainly some old > systems still running that use some obscure features. > > In order to not alienate long time users from fvwm we may need to > make a clean cut at some time: > > * Up to version X, the old feature set and syntax is supported >"forever". There won't be any new features anymore, but if >need be, we'll look into fixes like to new library versions and >such, so that the old version will continue to run on old boxes. >Patches fixing such problems are welcome, and once in a while a >new maintenance release is made. I've given this a lot of thought, and certainly with the changes I am looking to make, it's a lot of work to do that without radically changing things for existing users. To be clear, I mean such changes are compounded by trying to be backwards compatible. Having a clean break means it allows us to architect things differently; to really think about things, and to not let so many of the feature we have now, grow organically, obtrusively, and more importantly, without discussion. This was something I struggled with when looking at mvwm---ripping out all of the things which were getting in the way of having something cleaner to allow changes was impossible given how everything inter-relates. On the back of the current TODO.md file, I'll draft a list of key-features as I see them and send it out for review/discussion here. > * From version X+1 onwards, no guarantees are made about >continued support of obscure features, until there's an >official fvwm-3.0. I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be the last stable/supported version. Up to this point I've installed all optional libraries and fixed all the warnings for the versions I have available (FreeBSD) -- so that's something. I think it's in a good state to be left behind, and allowing it to receive minor fixes, etc. Questions? Do please ask. Kindly, Thomas
Re: Final long term stable version
On Mon, Oct 17, 2016 at 11:25:47PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > > While the enthusiasm to remove outdated stuff (strokes, Xinerama, > > colourmaps, old parser etc.) is an important step towards a > > maintainable and nice future fvwm3, there are certainly some old > > systems still running that use some obscure features. > > > > In order to not alienate long time users from fvwm we may need to > > make a clean cut at some time: > > > > * Up to version X, the old feature set and syntax is supported > >"forever". There won't be any new features anymore, but if > >need be, we'll look into fixes like to new library versions and > >such, so that the old version will continue to run on old boxes. > >Patches fixing such problems are welcome, and once in a while a > >new maintenance release is made. > > > > * From version X+1 onwards, no guarantees are made about > >continued support of obscure features, until there's an > >official fvwm-3.0. > > > > Is that doable? WIth X == 2.6.7? (Of course this is all depends > > on people actually doing that work.) > > It's doable from a code/maintenance point of view, yes. But I hope that > there's no real expectation that developers or future developers (chance would > be a fine thing!) who might be working on this mythical fvwm-3, should care > about fvwm-legacy. > > Oh, and I love the idea---but I am incredibly skpetical about it coming to > fruition, given that there are so few people developing fvwm these days. Well, developers or not is one thing, but the first step would be to *announce* that fvwm2 is not going to be disposed off on the compost heap. That anybody is welcome if she wants to take care of the fvwm2 branch for a while, and that the "fvwm3" developers are not going to put a spoke in her wheel, and support that maintenance work if possible. (If it turns out that there are no developers for fvwm this discussion is moot anyway.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > While the enthusiasm to remove outdated stuff (strokes, Xinerama, > colourmaps, old parser etc.) is an important step towards a > maintainable and nice future fvwm3, there are certainly some old > systems still running that use some obscure features. > > In order to not alienate long time users from fvwm we may need to > make a clean cut at some time: > > * Up to version X, the old feature set and syntax is supported >"forever". There won't be any new features anymore, but if >need be, we'll look into fixes like to new library versions and >such, so that the old version will continue to run on old boxes. >Patches fixing such problems are welcome, and once in a while a >new maintenance release is made. > > * From version X+1 onwards, no guarantees are made about >continued support of obscure features, until there's an >official fvwm-3.0. > > Is that doable? WIth X == 2.6.7? (Of course this is all depends > on people actually doing that work.) It's doable from a code/maintenance point of view, yes. But I hope that there's no real expectation that developers or future developers (chance would be a fine thing!) who might be working on this mythical fvwm-3, should care about fvwm-legacy. Oh, and I love the idea---but I am incredibly skpetical about it coming to fruition, given that there are so few people developing fvwm these days. But, yeah, I'm all for this. -- Thomas Adam
Final long term stable version
While the enthusiasm to remove outdated stuff (strokes, Xinerama, colourmaps, old parser etc.) is an important step towards a maintainable and nice future fvwm3, there are certainly some old systems still running that use some obscure features. In order to not alienate long time users from fvwm we may need to make a clean cut at some time: * Up to version X, the old feature set and syntax is supported "forever". There won't be any new features anymore, but if need be, we'll look into fixes like to new library versions and such, so that the old version will continue to run on old boxes. Patches fixing such problems are welcome, and once in a while a new maintenance release is made. * From version X+1 onwards, no guarantees are made about continued support of obscure features, until there's an official fvwm-3.0. Is that doable? WIth X == 2.6.7? (Of course this is all depends on people actually doing that work.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
