On Sep 30, 2016 7:57 AM, "Ian Romanick" <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>> wrote: > > On 09/30/2016 06:23 AM, Brian Paul wrote: > > On 09/30/2016 04:59 AM, Emil Velikov wrote: > >> On 30 September 2016 at 03:31, Timothy Arceri > >> <<a href="mailto:timothy.arceri@collabora.com">timothy.arceri@collabora.com</a>> wrote: > >>> On Thu, 2016-09-29 at 19:17 -0700, Jason Ekstrand wrote: > >>> > >>> On Sep 29, 2016 5:14 PM, "Timothy Arceri" <<a href="mailto:timothy.arceri@collabora.com">timothy.arceri@collabora.com</a>> > >>> wrote: > >>>> > >>>> On Thu, 2016-09-29 at 15:56 +0100, Emil Velikov wrote: > >>>>> On 28 September 2016 at 19:53, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> It's been almost 4 months since the 12.0 branch was created, and > >>>>>> soon > >>>>>> it will have been 3 months since Mesa 12.0 was released. > >>>>>> > >>>>>> Is there any reason we haven't created the stable branch yet? > >>>>>> > >>>>>> Ideally, we would time the release so that it's 1-2 months before > >>>>>> fall > >>>>>> distribution releases. > >>>>>> > >>>>> > >>>>> Thanks Marek ! > >>>>> > >>>>> In all honesty I was secretly hoping that we'll get Dave/Bas RADV for > >>>>> 12.1. > >>>> > >>>> I believe the release should be 13?? Core Mesa and the Intel driver > >>>> have reached 4.4 this release also core Mesa is now at 4.5 despite not > >>>> being enabled anywhere. > >>> > >>> My personal preference, for whatever it's worth, would be to call it > >>> 12.1. > >>> The 12.0 release was the biggest release we've had in a long time and it > >>> seems odd to me to jump to 13.0 right away when we really haven't > >>> done much > >>> at all in terms of new features. (I think it's only 2 or 3 desktop > >>> features > >>> in the case of Intel. A bit more on the ES side I guess). > >>> > >>> > >>> My understanding is the major version has only ever been bumped when > >>> full > >>> support for a new desktop OpenGL version has been reached regardless > >>> of the > >>> number of extensions enabled. We did the same thing going from 8.0 > 9.0 > >>> were as the 7 release went all the way to 7.11 over a 4 year period. It > >>> seems odd to change the way we bump versions at this point in time, > >>> although > >>> in future maybe it will need to be based on Vulkin versions also. > >>> > >> Brain freeze - seem to miss-remember that enhanced layouts (thus 4.4) > >> landed after the branch point. > >> That plus the ES3.1/ES3.2, compat for the desktop GL, (by Ilia/Ken) > >> does take us to 13.0. > >> > >> At the end of the day it's just a number albeit being the "unlucky" one. > >> > >> If we get a consensus amongst the majority of devs we can change the > >> versioning scheme. But for that let's do so in a ~weeks time - after > >> the branchpoint. > > > > I'd say to go to 13.0 if we're now supporting GL 4.4. That'd follow the > > general pattern. > > I agree. The only question is what we do after GL 4.5 bumps us to 14.0. > There is a distinct possibility (spoiler alert) that there won't be any > new OpenGL version for a long time, if ever. Will we be stuck at 14.x > forever? :) I think at dune point we probably just want to move to some other scheme for when to do major releases. The real question is when and to what do we switch. I've already argued that the jump from 4.4 to 4.3 is fairly artificial since the only part of 4.4 we were missing in 12.0 was a part of one extension (enhanced layouts). The jump from 4.4 to 4.5 is even more artificial since we already have all the 4.5 features and just haven't bumped the number. Here's some options on the "what" part of the question: 1) We should do a time-based scheme like the kernel uses. Release minor versions every 3 months and major versions every N years. 2) Keep with the current scheme and throw Vulkan into the mix. Mesa 15.0 will be when we add support for Vulkan 1.1. We could also throw in ES but that doesn't help since we just turned on 3.2 and ES is about as likely to get a 3.3 as desktop is to get 4.6. 3) Just do minor releases and let developers nominate any release to be a major one based on some major event in their driver. This is quite arbitrary but at least gives is the chance to try and make a new major release actually mean something major happened. 4) Do what chromium, Firefox, and some other projects have done and just get rid of major/minor all together. I think I actually like (4) the best. It's not like we're a library that's going to break ABI ever and needs a major version boundary to do it on. I think it also better represents the actual development model of the project going forward where each release is a bit better than the others but most aren't that much more major then the others. > > I'm updating docs/intro.html with version 10.x - 12.x info. > > > > -Brian > > > > _______________________________________________ > > mesa-dev mailing list > > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> > > _______________________________________________ > mesa-dev mailing list > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>