<div dir="ltr"><div>I see.</div><div><br></div><div>It will be 2.year.n then unless there are objections.</div><div><br></div><div>Marek<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 11, 2019 at 12:47 PM Dylan Baker <<a href="mailto:dylan@pnwbakers.com">dylan@pnwbakers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Quoting Eric Engestrom (2019-10-11 06:10:58)<br>
> On Thursday, 2019-10-10 16:14:47 -0400, Marek Olšák wrote:<br>
> > Hi,<br>
> > <br>
> > I expect to make a new libdrm release soon. Any objections to changing the<br>
> > versioning scheme?<br>
> > <br>
> > Current: 2.4.n<br>
> > n = starts from 0, incremented per release<br>
> > <br>
> > New proposals:<br>
> > year.n.0 (19.0.0)<br>
> > year.month.n (19.10.0)<br>
> > year.month.day (19.10.10)<br>
> <br>
> Sounds good, but I really suggest the Mesa scheme of counting release<br>
> and not a purely date-based system (we'd had bursts of releases in the<br>
> past, sometimes more than one in the same day).<br>
> <br>
> One suggestion might be to bump the minor version instead of the major?<br>
> To be more precise: 2.year.n, where year is 19 so 2.19.x > 2.4.x<br>
> <br>
> Thoughts?<br>
<br>
I prefer this to <year>.<any><br>
<br>
To echo Dave's concern, if we ever decided to have a non-backwards compatible<br>
API change (say Intel decided that since we don't use libdrm_intel anymore we<br>
don't want to maintain it and want to drop it) we'd need to be able to bump the<br>
major version to signal that to downstreams.<br>
<br>
Mesa doesn't have this problem because were' implementing Khronos APIs: the<br>
mesa version and the libs don't match anyway.<br>
<br>
Dylan<br>
</blockquote></div></div>