Pointier point releases
Daniel van Vugt
daniel.van.vugt at canonical.com
Mon Mar 10 03:58:49 UTC 2014
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
>
More information about the Mir-devel
mailing list