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