4 ms·

Great question - I've thought a lot about backward compatibility but I don't have a good answer yet. The whole Python 2 vs 3 nightmare has given me a couple sle

Great question - I've thought a lot about backward compatibility but I don't have a good answer yet. The whole Python 2 vs 3 nightmare has given me a couple sleepless nights though.

earenndil 7y ago
May I recommend d's scheme? I personally find it works quite well. Essentially, breaking features are introduced as a 'preview' that you have to opt into with a compiler flag. After a period of some time, it is changed so that the old and new behaviours can co-exist, but a deprecation warning is issued where the old behaviour is found. After some more time, the warning is changed to an error, but with an option flag to change it back to a deprecation. Then, finally, it is removed completely for the compiler. This makes the maintainers' job a bit harder, but not by a lot, and as a user I find it a nice medium of stability and progress.
- rmetzler 7y ago
  I don’t maintain much software with downstream users, but I would expect feature flags like this to make the job also easier for maintainers. It’s a little bit more code, but since you don’t break anything for your users you can take your time and don’t need to rush to push out fixes for new features, since these are opt-in first.
exikyut 7y ago
Consider three ecosystem saturation points: 1: No users: infinite flexibility 2: "Small" userbase: changes produce grumbling, community adjusts over time, old code is successfully forgotten (deleted + no nostalgia) 3: Very Large™ userbase: even TNT won't change the language Each of these is relative: (3) has happened with Python (famously explosively), Rust, Go... and also Lua, awk, FORTH. Language size ("volume") seems to have no impact; once a language becomes known for a certain way of doing things beyond a certain scale, trying to go against that (even as the language creator) will land you in a strange, undefined uncanney valley that's not precisely un-idiomatic, but... everyone will still try and steer/corral/etc you back to the "established way". Obviously (2) represents the perfect ideal here. (Well it wins by default, since (1) is socially depressing :) ) So, one approach could be to try lots of ideas (at a pace that keeps up the creative energy to enjoy the effort) early on. The key in this case seems to be figuring out the magic threshold point where the community is - large enough to provide constructive feedback and help the project substantively grow - small enough to stomach fundamental, relearn-everything-you-learned, changes - cohesive enough not to be disbanded by the impact of said changes and carefully ratelimiting publicity and knowledge spread to control ecosystem growth, in a way that does not rein it in. The dynamics of what defines this balance seem to be specific to each project.

Great question - I've thought a lot about backward compatibility but I don't have a good answer yet. The whole Python 2 vs 3 nightmare has given me a couple sleepless nights though.

earenndil 7y ago

May I recommend d's scheme? I personally find it works quite well. Essentially, breaking features are introduced as a 'preview' that you have to opt into with a compiler flag. After a period of some time, it is changed so that the old and new behaviours can co-exist, but a deprecation warning is issued where the old behaviour is found. After some more time, the warning is changed to an error, but with an option flag to change it back to a deprecation. Then, finally, it is removed completely for the compiler. This makes the maintainers' job a bit harder, but not by a lot, and as a user I find it a nice medium of stability and progress.

rmetzler 7y ago
I don’t maintain much software with downstream users, but I would expect feature flags like this to make the job also easier for maintainers. It’s a little bit more code, but since you don’t break anything for your users you can take your time and don’t need to rush to push out fixes for new features, since these are opt-in first.

exikyut 7y ago

Consider three ecosystem saturation points: 1: No users: infinite flexibility 2: "Small" userbase: changes produce grumbling, community adjusts over time, old code is successfully forgotten (deleted + no nostalgia) 3: Very Large™ userbase: even TNT won't change the language Each of these is relative: (3) has happened with Python (famously explosively), Rust, Go... and also Lua, awk, FORTH. Language size ("volume") seems to have no impact; once a language becomes known for a certain way of doing things beyond a certain scale, trying to go against that (even as the language creator) will land you in a strange, undefined uncanney valley that's not precisely un-idiomatic, but... everyone will still try and steer/corral/etc you back to the "established way". Obviously (2) represents the perfect ideal here. (Well it wins by default, since (1) is socially depressing :) ) So, one approach could be to try lots of ideas (at a pace that keeps up the creative energy to enjoy the effort) early on. The key in this case seems to be figuring out the magic threshold point where the community is - large enough to provide constructive feedback and help the project substantively grow - small enough to stomach fundamental, relearn-everything-you-learned, changes - cohesive enough not to be disbanded by the impact of said changes and carefully ratelimiting publicity and knowledge spread to control ecosystem growth, in a way that does not rein it in. The dynamics of what defines this balance seem to be specific to each project.