Pointier point releases

[Daniel van Vugt]

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
>