[Rock-dev] Minutes of Rock Core videoconference

[Sylvain Joyeux]

> 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