> Bad wording, I meant breaking of compatibility. With the > rule of waiting for 1 to 2 releases (depends when the patch > would enter) one will need about a year for any critical change. > This is just not feasible.
Given that it is being done right now, experience shows that it is quite feasible > I don't get the point. At some point the backward compatibility > will break, even if you delay it. So in the end it does not make a > difference, as one needs to port his/her software anyway. Because people are warned and have two releases to update their code (as you point out yourself, almost a year). The alternative: they get a new release and have to update RIGHT NOW or they can't use new releases. Actually, this would be the nail in the coffin of the idea for me: breaking backward compatibility in master means that non-core packages must depend either on core master or core stable. But either not both, or have a lot of shitty ifdefs in them. > For the ROS example, I don't think that we have 'users'. Core > packages have been crippled for weeks and nobody noticed it. > I would propose that we actually acquire real data about the > amount of people that use rock and adjust our policies to this. > A good way of doing this would be to send a message to a > server on every autoproj update (implemented in the init.rb in the > rock.core package set). (1) If you write policies on the basis that we don't have users, then we will never have any. (2) This is not about master. If we had released "crippled master" as stable, then a lot of people would have noticed. If you break backward compatibility in master, you eventually break it in the next release. That's what the "users" will see. Actually, that would also be a role of master: to make sure we can maintain backward compatibility. > There is a maintenance cost. Perhaps not a imminent cost, but still work: > You still need to remove the code, to clean it up. Which you need to do anyways. > So someone needs to > keep track of what may be removed now, or what is still in the 'deprecation' > phase. Given that, regardless of the policy we agree on in fine, you would have to announce backward-incompatible changes, the tracking has to be done anyways. As soon a deprecation is put in a release release notes, tracking it is a no-brainer. > Removing the code right away would lower the workload. On that we agree. And, as a project, we have to decide where best to spend "groundwork" workload. > Worst case scenario. Every component would start to > use different types on the ports for the same thing. > This would basically make everything incompatible. Which is why we need to implement on-the-wire conversions to allow for smooth transitions (for which a lot of work has already been done in RTT). Which would also give us full support for inheritance (as we would get subclass-to-superclass connections) and finally break the *need* for something like RBS in the first place. Kill two birds with one stone. Sylvain _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
