That's really bad! I have to think about a backwards-compatible solution ...
I hope to get back to UUID::Tiny soon to fix some bugs and do little improvements.
--
Christian Augustin
Am 2013-01-31 um 15:46 schrieb James Howe via RT <bug-UUID-Tiny@rt.cpan.org>:
Show quoted text
> Thu Jan 31 09:46:00 2013: Request 83073 was acted upon.
> Transaction: Ticket created by james.howe@cantab.net
> Queue: UUID-Tiny
> Subject: Variant not set
> Broken in: (no value)
> Severity: (no value)
> Owner: Nobody
> Requestors: james.howe@cantab.net
> Status: new
> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83073 >
>
>
> As per http://tools.ietf.org/html/rfc4122#section-4.1.1 the first 2
> bits of byte 8 should be set to 0b10.
>
Tue Jul 23 13:22:00 2013The RT System itself - Status changed from 'new' to 'open'
Mon Aug 19 09:56:48 2013CAUGUSTIN [...] cpan.org - Correspondence added
UUID::Tiny sets the variant as specified in byte 8 – this is the 9th byte as the RFC starts counting bytes with 0. All generated UUIDs conform to the RFC as far as I can see (a more palatable description of UUIDs can be found on Wikipedia at http://en.wikipedia.org/wiki/Universally_unique_identifier).
If UUIDs occur that do not conform, please send me some samples so that I can further investigate.
Mon Aug 19 09:56:49 2013CAUGUSTIN [...] cpan.org - Status changed from 'open' to 'rejected'
Mon Aug 19 10:20:10 2013james.howe [...] cantab.net - Correspondence added
Subject:
Re: [rt.cpan.org #83073] Variant not set
Date:
Mon, 19 Aug 2013 15:19:52 +0100
To:
bug-UUID-Tiny [...] rt.cpan.org
From:
James Howe <james.howe [...] cantab.net>
Either I was looking at an older version. Or it's the other library I
was working with that did it wrong.
UUID::Tiny 1.03 does seem to be doing the right thing.
On 19 August 2013 14:56, Christian Augustin via RT
<bug-UUID-Tiny@rt.cpan.org> wrote:
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=83073 >
>
> UUID::Tiny sets the variant as specified in byte 8 – this is the 9th byte as the RFC starts counting bytes with 0. All generated UUIDs conform to the RFC as far as I can see (a more palatable description of UUIDs can be found on Wikipedia at http://en.wikipedia.org/wiki/Universally_unique_identifier).
>
> If UUIDs occur that do not conform, please send me some samples so that I can further investigate.
Mon Aug 19 10:31:00 2013cma [...] snafu.de - Correspondence added
Subject:
Re: [rt.cpan.org #83073] Variant not set
Date:
Mon, 19 Aug 2013 16:30:44 +0200
To:
bug-UUID-Tiny [...] rt.cpan.org
From:
Christian Augustin <cma [...] snafu.de>
Thanks for the confirmation!
--
Christian Augustin
Am 2013-08-19 um 16:20 schrieb "James Howe via RT" <bug-UUID-Tiny@rt.cpan.org>:
Show quoted text
> Queue: UUID-Tiny
> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83073 >
>
> Either I was looking at an older version. Or it's the other library I
> was working with that did it wrong.
> UUID::Tiny 1.03 does seem to be doing the right thing.
>
> On 19 August 2013 14:56, Christian Augustin via RT
> <bug-UUID-Tiny@rt.cpan.org> wrote:
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=83073 >
>>
>> UUID::Tiny sets the variant as specified in byte 8 – this is the 9th byte as the RFC starts counting bytes with 0. All generated UUIDs conform to the RFC as far as I can see (a more palatable description of UUIDs can be found on Wikipedia at http://en.wikipedia.org/wiki/Universally_unique_identifier).
>>
>> If UUIDs occur that do not conform, please send me some samples so that I can further investigate.
RT for rt.cpan.org