[Mesa-dev] Proposal of date-based Mesa versioning for 2017

Albert Freeman albertwdfreeman at gmail.com
Tue Oct 4 04:09:11 UTC 2016


Yeah I think the value of having a date based system is to quickly
check when the release was made, dayoutofdaysthatyear isn't really
providing any extra benefit since its hard to read and that extra info
is probably rather pointless for quick fix releases since the mesa-dev
branch and a quick fix release wouldn't be syncronised (which also
could cause confusion).
I also don't think people are really going to have a problem with
skipped version numbers anyway (at least not one of concern). I think
its best to just ignore that and do what is best for the future.
So yes, dayoutofdaysthatyear is a detrimental system.
Though I also think that keeping to a quaterly release schedule is a
bad idea. Probably better to try to pick all the dates which align
best with major distros and/or release when something of major value
gets developed. What matters more: sticking to a schedule that fits
seasons of the year just because humans feel like it, or getting
features out to users as quickly as possible.
If releases only happen 3 times a year some years then it will just
create confusion if people are trying to interpret minor versions as
quaterly periods, you would have to remember which years are quaterly.
Though I am just trying to help, I personally don't care what release
system is chosen, so you need not take my opinion into consideration.

On 3 October 2016 at 09:40, Jason Ekstrand <jason at jlekstrand.net> wrote:
>
> On Oct 3, 2016 12:19 AM, "Albert Freeman" <albertwdfreeman at gmail.com> wrote:
>>
>> year.month or year.dayoutofdaysthatyear
>
> Why are we adding more options to an already confused discussion?
>
>> dayoutoofdaysthatyear skips lots of integers quickly: reducing
>> confusion of where is release x.(y - something) and better handles
>> quick fix releases
>> but makes it harder to determine how far into the year the release is
>> although with some effort can be converted into an exact date
>
> Quick fix releases are already handled by the stable release system which I
> don't think anyone is recommending we get rid of.  Also, I haven't heard
> anyone complain that year.quarter (really, year.releaseofyear) isn't
> shipping enough integers.  I don't see what problem your suggestion is
> solving.
>
>> On 2 October 2016 at 14:22, Tobias Klausmann
>> <tobias.johannes.klausmann at mni.thm.de> wrote:
>> >
>> >
>> > On 02.10.2016 13:56, Nicolai Hähnle wrote:
>> >>
>> >> On 01.10.2016 22:22, Tobias Klausmann wrote:
>> >>>
>> >>> On 01.10.2016 21:46, Marek Olšák wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> I propose that we use versioning in the form of "year.quarter".
>> >>>>
>> >>>> 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following
>> >>>> quarters of the year, respectively.
>> >>>> 2018 would start with 18.0, then 18.1, 18.2, 18.3.
>> >>>>
>> >>>> The motivation is that you can easily tell when a specific Mesa
>> >>>> version was released with an accuracy of 3 months.
>> >>>>
>> >>>> That's the only scheme that seems practical to me. Everything else
>> >>>> seems arbitrary or random.
>> >>>>
>> >>>> Opinions?
>> >>>
>> >>>
>> >>> Why not just use year.month instead, would be more accurate...and
>> >>> releases happen semi random anyway and not after a given time.
>> >>
>> >>
>> >> That's fine for something like Ubuntu where they really stick to their
>> >> two
>> >> releases per year, in the same months each year. I'm not so sure that
>> >> that's
>> >> a realistic goal for Mesa, and if releases *aren't* consistently
>> >> happening
>> >> in the same months, you end up introducing a lot of confusion about
>> >> which
>> >> version numbers exist and which don't.
>> >
>> >
>> > This is true, but also holds true for year.quarter, if we miss one
>> > quarterly
>> > release (18.1, 18.2, 18.4, whoops where is 18.3).
>> >
>> >>
>> >> Time-based with YY.0 for the first release of the year, and then YY.1,
>> >> YY.2, etc. works fine.
>> >
>> >
>> > Thats allright and would help in not confuse people so much, but with it
>> > you
>> > miss the "when was it released again?" thing Marek tried to introduce.
>> >
>> > Greetings,
>> > Tobias
>> >
>> >
>> >>
>> >> Cheers,
>> >> Nicolai
>> >
>> >
>> > _______________________________________________
>> > 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


More information about the mesa-dev mailing list