Re: [E-devel] Defining the micro/revision versions on public headers

2012-08-25 Thread Raphael Kubo da Costa
Carsten Haitzler (The Rasterman) writes: > if they have binary pkgs - they they dont have headers either. basically pc > files, headers etc. are part of the dev/devel pkgs that go alongside the lib > core binary ones and so a dev/devel pkg without pc files is a broken/useless > one. so you can as

Re: [E-devel] Defining the micro/revision versions on public headers

2012-08-23 Thread The Rasterman
On Fri, 24 Aug 2012 00:55:55 -0300 Raphael Kubo da Costa said: > Carsten Haitzler (The Rasterman) writes: > > > the rationale is that micro versions do not have anything change in a header > > that would affect compatibility forwards or backwards. we shouldnt be adding > > features in micro rel

Re: [E-devel] Defining the micro/revision versions on public headers

2012-08-23 Thread Raphael Kubo da Costa
Carsten Haitzler (The Rasterman) writes: > the rationale is that micro versions do not have anything change in a header > that would affect compatibility forwards or backwards. we shouldnt be adding > features in micro releases (adding enums, struct members, functions etc.). > thus > there is no

Re: [E-devel] Defining the micro/revision versions on public headers

2012-08-23 Thread The Rasterman
On Thu, 23 Aug 2012 15:49:50 -0300 Raphael Kubo da Costa said: > So far, modules such as eina, evas and friends only define their major > and minor versions on public headers such as Evas.h. > > While this is OK most of the time, one might also need to check the > micro version as well -- my cur

[E-devel] Defining the micro/revision versions on public headers

2012-08-23 Thread Raphael Kubo da Costa
So far, modules such as eina, evas and friends only define their major and minor versions on public headers such as Evas.h. While this is OK most of the time, one might also need to check the micro version as well -- my current use case is performing version checks without having to rely on pkg-co