Reply to thread

Message

<blockquote data-quote="mm1352000" data-source="post: 1056017" data-attributes="member: 82144">Hmmm, recompiled...I'm not a plugin dev so maybe this comment should just be ignored, but I have the impression that every release we seem to do something that requires plugin changes or recompilation to maintain compatibility. It feels like this is happening more frequently than in the past, and not just because of the more frequent releases.In the past we actively tried to avoid breaking changes or planned them in such a way that such changes were in a single release, then we would try to avoid/delay new breaking changes for the next release or two. The train process currently says any change that is ready can be merged.I informally propose that the train process could benefit by having some acceptance/merging criterion/criteria added to avoid this situation of breaking changes every release. Could we say something like: breaking plugin changes only allowed once every second release?Again: I'm obviously not a plugin dev. Just have the feeling that the less active or busy or otherwise occupied plugin developers that don't closely follow our internal release and testing process... I'm concerned they would get frustrated with every 3 months or so having another reason to have to recompile or release a new version outside (on top of) their own normal release processes. These are exactly the people that are unlikely to say anything to the team directly...</blockquote>

[QUOTE="mm1352000, post: 1056017, member: 82144"] Hmmm, recompiled... I'm not a plugin dev so maybe this comment should just be ignored, but I have the impression that every release we seem to do something that requires plugin changes or recompilation to maintain compatibility. It feels like this is happening more frequently than in the past, and not just because of the more frequent releases. In the past we actively tried to avoid breaking changes or planned them in such a way that such changes were in a single release, then we would try to avoid/delay new breaking changes for the next release or two. The train process currently says any change that is ready can be merged. I informally propose that the train process could benefit by having some acceptance/merging criterion/criteria added to avoid this situation of breaking changes every release. Could we say something like: breaking plugin changes only allowed once every second release? Again: I'm obviously not a plugin dev. Just have the feeling that the less active or busy or otherwise occupied plugin developers that don't closely follow our internal release and testing process... I'm concerned they would get frustrated with every 3 months or so having another reason to have to recompile or release a new version [B]outside (on top of) their own normal release processes.[/B] These are exactly the people that are unlikely to say anything to the team directly... [/QUOTE]

Verification