On Wed, 2009-12-02 at 18:27 -0800, David Brownell wrote: > On Wednesday 02 December 2009, Zach Welch wrote: > > > For now, we could make the init's mode=COMMAND_ANY. That should be a > > temporary fix that solves your regression, > > It did ... letting me focus on the funkier issues I was wanting to > chase, instead of "init" breaking. :) > > I think that should be the longer term fix. What's the advantage > to that change in "init" semantics? "Makes things harder to use" > doesn't seem win-like to me! > > > > though the other 'init' > > commands may need similar treatment. > > > > As far as backwards-compatibility, I have started thinking about cutting > > 1.0 for the sake of dropping it. If we _care_ about backwards > > compatibility, then we are already treating the code like the 1.0 branch > > and the 0.x name is misleading and detrimental to our image. > > I don't see that. With *any* release there's the expectation that it > hasn't broken compatibility with the previous one ... unless there were > all sorts of warning flags. And the only policy I've ever seen in this > project is that there should be plenty of advance notice for changes > that break compatibility; "a year or so" was the time frame ISTR was > discussed earlier this year. (And so it's the upcoming release which > drops compatibility with some commands folk were warned away from > starting in autumn of 2008...) > > If there's no expectation of compatibility, it might as well be > called a fork and given a new project name.
That was my point. Fork OpenOCD 2.0 and warn it's not compatible. > > > If so, > > then cut 0.4.0 as 1.0, and let's drop the charade that developers have > > freedom to change stuff. That's what 0.x means to me. > > It's never meant that to me, on any product. There's always the > constraint to avoid breaking users. (It's possible that serious > bug fixes will require that. That doesn't match this change.) > > There's still freedom to change stuff. Just ... not to do so in > ways that prevent dropping the next release into the slot that's > now occupied by the current one, and which isn't giving warnings > about dubious practice. The problem with this is that it assumes the status quo is not itself one big design bug. Still, I will be happy to maintain the present feature set, as this strips all motivation to improve it further. It does, however, motivate me to continue isolating the existing TCL language support completely, so it can be replaced with a new language. Deprecation of the old language can be done wholesale, once the new one is in place and working. They can coexist without breaking each other, and it gives the freedom that I want to have without having to fork. This is the high road... in more ways than one. --Z _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
