Pointier point releases

Kevin Gunn kevin.gunn at canonical.com
Mon Mar 10 15:52:12 UTC 2014


I'm +1 in general on the proposal.
The only thing I would correct is expectations. I think what we've proven
over the last several months is that we do actually require ABI update for
the server more weekly than monthly.

Also, we have become fairly disciplined at bumping the server .so name on
the dev branch at the point of breaking ABI or API. Which is extremely
helpful, speaking as the person designated to ride the "CI train" at the
moment. However, we had one sneak in recently...from memory,
configure_output removed.

I think the more important problem to solve for the team is to have a
centralized/remote way of building the latest dev branch + updated known
dependent components (unity-mir, platform-api,
unity-system-compositor...note, i'm leaving out xorg-server atm since its
only client api). Not only for folks to be able to easily test cooperative
features that might span say mir & unity-mir, but to also catch the
accidental server break.

I've been wrestling with using launchpad ppa, which I just want to share
has some idiosyncrasies not readily apparent. First, if you just use the
launchpad ppa builders as is, you are built on a virtualized hardy kernel -
so you have to ask to be non-virtualized from webops. Second, if you run
our Mir android integration tests they fail due to lacking access to the gl
drivers. So the ppa builders aren't quite the same as the builders on our
"dev branch ci runs" - however more similar to our "ci train" silo builds.

In parallel to me trying to get a ppa working for mir-dev, unity-mir,
platform-api, & unity-system-compositor. I think Robert was going to chase
a solution to do this with our jenkins jobs used on our dev-branch. And, I
hope he beats me in that race :) as the jenkins runs have the android
driver capability.

br,kg



On Sun, Mar 9, 2014 at 10:58 PM, Daniel van Vugt <
daniel.van.vugt at canonical.com> wrote:

> A nice clean way to approach this is to designate Mir version numbers like
> this (partly based on the current patterns):
>
> 0.1.7  Bug fixes
> 0.1.8  Bug fixes
> 0.2.0  Server ABI bump / bug fixes
> 0.2.1  Bug fixes
> 0.2.2  Bug fixes
> 0.2.3  Bug fixes
> 0.3.0  Server ABI bump / bug fixes
> 0.3.1  Bug fixes
> 1.0.0  Client ABI bump / server ABI bump / bug fixes
>
> "Bug fixes" can also include any enhancements which don't break the ABIs.
> So effectively a Mir version number would become:
>
> MIR_VERSION = CLIENT_ABI . SERVER_ABI_DECIMAL . FIX_REVISION
> SERVER_ABI = CLIENT_ABI . SERVER_ABI_DECIMAL
>
> This means the expected frequency (which I think is realistic) would be:
>
> Bug fixes: Very regularly (daily/weekly)
> Server ABI change: Less regular (one or two per month, to limit package
> rebuild pain).
> Client ABI change: Very seldom, none planned.
>
> This is actually quite a simple plan to implement. We don't have any
> client ABI changes on the horizon just yet, but when we do that can form
> the basis of choosing "1.0.0".
>
> - Daniel
>
>
> On 07/03/14 14:42, Daniel van Vugt wrote:
>
>> I notice how non-trivial it is to update all the projects, rebuilds and
>> packages every time we need to integrate a new Mir release into touch.
>>
>> But we could make this much easier if the Mir team consciously separated
>> ABI-break releases from smaller (and more frequent) minor releases. This
>> would allow us to install most smaller Mir releases without having to
>> update any other projects/packages. It just requires a little planning
>> by the Mir team to somehow "save up" and separate ABI-changing
>> proposals. I think the trouble might be worthwhile for the benefit we'd
>> get in being able to do instant system integration testing on touch
>> images.
>>
>> For example, given we roughly do a Mir release every 2-3 weeks now, we
>> could instead do:
>>
>> A minor release more often, every week or so (no ABI changes).
>> A larger release (ABI break) with more intrusive changes less often
>> (like monthly?).
>>
>> - Daniel
>>
>>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20140310/99b938f8/attachment.html>


More information about the Mir-devel mailing list