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. > 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. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
