Merge lp://qastaging/~sil2100/compiz/compiz_abi_bump into lp://qastaging/compiz/0.9.8

Proposed by Łukasz Zemczak
Status: Merged
Approved by: Daniel van Vugt
Approved revision: 3404
Merged at revision: 3405
Proposed branch: lp://qastaging/~sil2100/compiz/compiz_abi_bump
Merge into: lp://qastaging/compiz/0.9.8
Diff against target: 11 lines (+1/-1)
1 file modified
include/core/abiversion.h (+1/-1)
To merge this branch: bzr merge lp://qastaging/~sil2100/compiz/compiz_abi_bump
Reviewer Review Type Date Requested Status
Daniel van Vugt Approve
jenkins continuous-integration Pending
Review via email: mp+126890@code.qastaging.launchpad.net

This proposal supersedes a proposal from 2012-09-28.

Commit message

Unity fails to work with the new compiz since composite has a new ABI version (changed from 4 to 5). Since unity needs to be rebuilt to work with the new compiz, we need compiz to have its ABI bumped. Since that's an obvious ABI bump...

Didier insists.

Description of the change

Unity fails to work with the new compiz since composite has a new ABI version (changed from 4 to 5). Since unity needs to be rebuilt to work with the new compiz, we need compiz to have its ABI bumped. Since that's an obvious ABI bump...

Didier insists.

To post a comment you must log in.
Revision history for this message
jenkins (martin-mrazik+qa) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

I can see composite did change in r3391, but Sam did remember to increment COMPIZ_COMPOSITE_ABI already.

So why change the core ABI?

review: Needs Information
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

bzr status -rv0.9.8.2..v0.9.8.4
shows that no core headers, and hence the core ABI, has not changed. Although didrocks incremented the ABI between 0.9.8.2 and 0.9.8.4 already. I'm not sure why.

So it seems the core ABI has already been changed more than it should recently. It should not change again unless the actual ABI changes. That means the size of a class or virtual methods change in one of the public core headers. I haven't seen any such changes that affect the ABI for a while.

review: Disapprove
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Posted in a previous version of this proposal

Well, Didier recommends to change the global ABI, as from what he said, Sam was already doing it previously when some plugins ABI was changing. He recommends to stick with this approach during this cycle and start doing it otherwise in the next one.

What do you think?

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

It makes no sense to increment the ABI number when the ABI itself has not changed.

But it's not worth arguing about right now.

Please just resubmit for lp:compiz first, before lp:compiz/0.9.8

review: Needs Resubmitting
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

Conflict :)

review: Needs Fixing
Revision history for this message
jenkins (martin-mrazik+qa) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
Daniel van Vugt (vanvugt) :
review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches