2016-12-12 20:01 GMT+01:00 Emil Velikov :
> [Re-adding mesa-maintainers]
>
> On 12 December 2016 at 18:08, Laurent Carlier wrote:
>> Le lundi 12 décembre 2016, 17:57:28 CET Marek Olšák a écrit :
>>>
>>> I second that. YY.AA where YY=year, AA \in {0,1,2,3}.
>>>
>>> Marek
>>
>> I agree, using month
Le lundi 12 décembre 2016 19:01:12 CET, vous avez écrit :
> Similar to the "libudev is no longer required by mesa" in the 13.0.0
> release notes ;-)
> Sorry I could not resist.
>
"Sticks and stones may break my bones, but words will
never hurt me." :)
--
Laurent Carlier
http://www.archlinux.org
[Re-adding mesa-maintainers]
On 12 December 2016 at 18:08, Laurent Carlier wrote:
> Le lundi 12 décembre 2016, 17:57:28 CET Marek Olšák a écrit :
>>
>> I second that. YY.AA where YY=year, AA \in {0,1,2,3}.
>>
>> Marek
>
> I agree, using month is really confusing
>
Similar to the "libudev is no lo
Le lundi 12 décembre 2016, 17:57:28 CET Marek Olšák a écrit :
>
> I second that. YY.AA where YY=year, AA \in {0,1,2,3}.
>
> Marek
I agree, using month is really confusing
--
Laurent Carlier
http://www.archlinux.org
signature.asc
Description: This is a digitally signed message part.
__
On Mon, Dec 12, 2016 at 7:28 AM, Emil Velikov wrote:
> * Should we drop the $VERSION directory in the URL, since it causes a
> fair bit of nuisance during RC stage.
> Namely from:
> https://mesa.freedesktop.org/archive/$VERSION/mesa-$VERSION.tar.{xz,gz}
> to:
> https://mesa.freedesktop.org/archiv
On Mon, Dec 12, 2016 at 8:57 AM, Marek Olšák wrote:
> On Mon, Dec 12, 2016 at 4:46 PM, Nicolai Hähnle
> wrote:
> > On 12.12.2016 16:41, Daniel Stone wrote:
> >>
> >> On 12 December 2016 at 15:28, Emil Velikov
> >> wrote:
> >>>
> >>> As mentioned by others - having the second number represent th
On Mon, Dec 12, 2016 at 6:04 PM, Jason Ekstrand wrote:
> On Mon, Dec 12, 2016 at 8:57 AM, Marek Olšák wrote:
>>
>> On Mon, Dec 12, 2016 at 4:46 PM, Nicolai Hähnle
>> wrote:
>> > On 12.12.2016 16:41, Daniel Stone wrote:
>> >>
>> >> On 12 December 2016 at 15:28, Emil Velikov
>> >> wrote:
>> >>>
>
On Mon, Dec 12, 2016 at 4:46 PM, Nicolai Hähnle wrote:
> On 12.12.2016 16:41, Daniel Stone wrote:
>>
>> On 12 December 2016 at 15:28, Emil Velikov
>> wrote:
>>>
>>> As mentioned by others - having the second number represent the month
>>> would be better, afaict.
>>> Namely: YY.MM.PP. Thus 17.02.
On 12 December 2016 at 15:41, Daniel Stone wrote:
> Hi,
>
> On 12 December 2016 at 15:28, Emil Velikov wrote:
>> As mentioned by others - having the second number represent the month
>> would be better, afaict.
>> Namely: YY.MM.PP. Thus 17.02.01 provides direct and clear feedback that
>> - 2017
On 12.12.2016 16:41, Daniel Stone wrote:
On 12 December 2016 at 15:28, Emil Velikov wrote:
As mentioned by others - having the second number represent the month
would be better, afaict.
Namely: YY.MM.PP. Thus 17.02.01 provides direct and clear feedback that
- 2017 release, from the second mont
Hi,
On 12 December 2016 at 15:28, Emil Velikov wrote:
> As mentioned by others - having the second number represent the month
> would be better, afaict.
> Namely: YY.MM.PP. Thus 17.02.01 provides direct and clear feedback that
> - 2017 release, from the second month (Feb).
> - first bugfix rele
[adding mesa-maintainers to the mix]
On 1 October 2016 at 20: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, the
On Tue, Oct 25, 2016 at 4:54 AM, Enrico Weigelt, metux IT consult
wrote:
> folks,
>
> are you looking for ways to make simple things complicated ?
>
> date-based versioning (eg. -MM) only makes sense, when you
> have an appropriate release schedule.
>
> I'd really prefer semantic versioning -
folks,
are you looking for ways to make simple things complicated ?
date-based versioning (eg. -MM) only makes sense, when you
have an appropriate release schedule.
I'd really prefer semantic versioning - especially for stable distros
and embedded systems (here you dont wanna do arbitrary up
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
On Oct 3, 2016 12:19 AM, "Albert Freeman" 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
> q
year.month or year.dayoutofdaysthatyear
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 conver
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, respectiv
On Sun, Oct 2, 2016 at 5:04 AM, Kenneth Graunke wrote:
> On Saturday, October 1, 2016 9:46:45 PM PDT 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, respec
I've seen many get confused by the fact that Ubuntu 16.10 is newer than
16.04, they think of it as 16.1 and 16.4. So avoiding that is nice.
Regards
//Ernst
2016-10-02 13:56 GMT+02:00 Nicolai Hähnle :
> On 01.10.2016 22:22, Tobias Klausmann wrote:
>
>> On 01.10.2016 21:46, Marek Olšák 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
On 10/02/2016 06:46 AM, 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
On Saturday, October 1, 2016 9:46:45 PM PDT 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.
>
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 ea
I could get behind that. The only other thing that makes sense to me would
be to drop minor versoning all together and just have an incrementing
integer (with patch releases for stable, of course). The year.quarter
scheme is fine with me too.
On Sat, Oct 1, 2016 at 12:46 PM, 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 r
26 matches
Mail list logo
