[Mesa-dev] Mesa 13.0.0 release plan (Was Re: Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?))

Fri Sep 30 15:32:25 UTC 2016

On Sep 30, 2016 7:57 AM, "Ian Romanick" <idr at freedesktop.org> 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
> >> <timothy.arceri at collabora.com> wrote:
> >>> On Thu, 2016-09-29 at 19:17 -0700, Jason Ekstrand wrote:
> >>>
> >>> On Sep 29, 2016 5:14 PM, "Timothy Arceri" <
timothy.arceri at collabora.com>
> >>> wrote:
> >>>>
> >>>> On Thu, 2016-09-29 at 15:56 +0100, Emil Velikov wrote:
> >>>>> On 28 September 2016 at 19:53, Marek Olšák <maraeo at gmail.com> 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
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160930/579ce806/attachment.html>