On Wed, 2014-03-12 at 23:30 -0400, Daniel Herring wrote:
On Wed, 12 Mar 2014, Faré wrote:
Major changes like that happen less than once a year (ASDF 2 in 2010, ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while backward-compatibility has always been a huge priority, improvements sometimes do mean the recommended way of using ASDF changes, for the better.
For essential infrastructure like what ASDF claims to be, I expect major changes to happen less than once every 5 to 10 years.
You can expect whatever you want, but unless somebody is paid full-time to work on ASDF, it's not going to happen.
The more backwards compatibility, the better. Projects like glibc have developed significant infrastructure to enable transparent improvements (see the ABI compliance checker, DSO symbol versioning, etc.).
See above. That kind of backwards-compatibility is very difficult and burdensome.
Every breaking change inflicts cost on a fraction of the existing userbase, in exchange for some proposed benefit to future users. Every time I have to debug breakage and change something or redesign my workflow to maintain existing capability, it encourages me to explore other, more stable or better designed options...
Sometimes "good ideas" fade after a month or two of reflection. Some survive the test because the benefit truly outweighs the cost. When that is the case, it is often helps to give the community time to prepare and minimize the number of times the community must change. So propose the change, allow a long RFC window, allow users to obtain test implementations (while still promoting the stable branch), wait a while for several changes to collect before pushing them into major new releases, etc.
I agree that an RFC-like process would be useful, instead of jumping in and implementing new features, as long as it's not too lengthy.