unity-dev team mailing list archive

[Daniel van Vugt <daniel.van.vugt@xxxxxxxxxxxxx>]

> Also, that we have to do that because there is a bad history of
> committing to ABI and API stability

That used to be true for Compiz but not true in recent history. Once a 
release 0.9.N.0 is completed we try not to change the ABI or API. Though 
0.9.9.0 for raring is not released yet so we reserve the right to change 
the ABI and API until then. If it happens again, I will be sure to 
update the dependency in Unity.

This reminds me -- bamf was broken for Unity a while back too (bamf from 
quantal is no longer good enough to build lp:unity as functions are 
missing). Someone needs to bump the dependency on bamf too.

- Daniel


On 07/01/13 14:35, Didier Roche wrote:
> Le 04/01/2013 20:38, Ted Gould a écrit :
> > On Fri, 2013-01-04 at 10:52 +0100, Didier Roche wrote:
> > > - Nux broke its API and ABI and the build-dependency requirement
> > > wasn't bumped on unity
> > > - Compiz broke its API and ABI and the build-dependency requirement
> > > wasn't bumped on unity
> > >
> > > Please, for the 2 laters, please bump the requirement on the
> > > depending package once you break the API. This is extremely important
> > > (and not the first time I have to do it myself) whereas quite easy to
> > > do in debian/control as you can see in the attached merge request:
> > > https://code.launchpad.net/~didrocks/unity/fix-ftbfs-2013/+merge/141876
> > > <https://code.launchpad.net/%7Edidrocks/unity/fix-ftbfs-2013/+merge/141876>
> >
> > This is actually impossible to do.  You were only able to do that
> > because you knew the revisions where the API changes were going to
> > land in.  But, since usually the Unity patch and the Nux patch are
> > developed in parallel, and which daily they'll land in are not
> > determinate (perhaps autolanding would fail) it's impossible to know
> > the version before landing, and especially when reviewing branches.
> >
> > We discussed this at UDS.  You told me it would hardly happen so
> > wasn't worth considering.  I don't think you can ask people to now
> > handle this in their development.  This is something you'll have to
> > continue to fix by hand when it happens as there's no way to know
> > enough information at development time.
>
> Ted, as part of the discussion at UDS, we told that it would just need
> to be previous release day +1, which is the day listed in
> debian/changelog and that everyone is aware about just looking at that
> file. Even if the day is not the day when it will be released, it will
> suffice in the sense it will build-dep on the right version.
>
> Also, that we have to do that because there is a bad history of
> committing to ABI and API stability, remember that normally, in every
> normal upstream project, such a breakage ask to change the soname, and
> in this case, we will know beforehand on which version of the -dev
> package to build-dep. We are just workarounding here bad upstream practice.
>
> Cheers,
> Didier