Don't you think that in the end, this is more a backward compatibility issue than a data model correctness issue?
Whatever the way we look at it, it is undeniable that 7.0 has changed the semantics of the partner_id field on business documents. And that has deep impacts everywhere.
Many good reasons for the change have been explained, but semantics changes must be made explicit by changing names. If this field had received any other name than partner_id (party_id, whatever), it would have been much easier to preserve backward compatibility to a great extend by (re)introducing partner_id as a read-only field.
IMHO, given the huge impact of this semantics change in community modules (and certified modules alike), preserving backward compatibility is totally worth an exception to the stable schema policy.
Don't you think that in the end, this is more a backward compatibility issue than a data model correctness issue?
Whatever the way we look at it, it is undeniable that 7.0 has changed the semantics of the partner_id field on business documents. And that has deep impacts everywhere.
Many good reasons for the change have been explained, but semantics changes must be made explicit by changing names. If this field had received any other name than partner_id (party_id, whatever), it would have been much easier to preserve backward compatibility to a great extend by (re)introducing partner_id as a read-only field.
IMHO, given the huge impact of this semantics change in community modules (and certified modules alike), preserving backward compatibility is totally worth an exception to the stable schema policy.