uuid6-ietf-draft VS spec

https://github.com/uuid6/uuid6-ietf-draft/issues/27

Why not UUIDv7?

What if a new UUID version could be designed that would take the randomness of UUID4 and combine it with a timestamp prefix? This would make the UUID increase overall, but not locally – due to the random postfix. The random part ensures uniqueness when a high generation rate is necessary and also makes the UUIDs hard to predict – it’s not possible to guess the previous, or next UUID. It’s fairly simple to devise a custom UUID scheme, but fortunately, there is a new Internet-Draft (at the time of writing) defining new pseudo-sequential UUID versions that aim to solve exactly this issue: draft-peabody-dispatch-new-uuid-format-04. The current state and progress can be viewed at IETF Datatracker.

Brad Peabody did the original -00 draft, which was discussed as an FYI at an IEFT meeting in March 2020. See [1], around 50 lines from the bottom.

Kyzer Davis has since submitted two further revisions -01 and -02 in April and October 2021. See history in [2].

The current -02 draft is due to expire in April 2022. Presumably Kyzer Davis will try to get it discussed before then.

The GitHub repo tracking these drafts is https://github.com/uuid6/uuid6-ietf-draft/.

[1] https://datatracker.ietf.org/meeting/107/materials/minutes-1...

[2] https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-...

At the moment anyway, that XML link won't render per an XML parsing error. For anyone who wants a quick look at what these XML docs look like here's one for UUID6 [0].

[0] https://github.com/uuid6/uuid6-ietf-draft/blob/master/draft-...

There was recently score.dev, but that is also just used by one tool.

Yesterday I was thinking about the roadmap and the discussions that are happening in the community (you can check them here and feel free to open one or contribute to an active one) and I am excited to see how much we have to look forward in 2023.

A month ago we open sourced Score. The community response has been really great so far (just over 1k stars in 4 weeks) and we got many questions thrown at us:

Hi all, I am Giulia, Community Manager and part of the team that launched Score.dev a week ago. My team and I believe that developers shouldn’t fight with tooling and advocate for a workload-centric approach to development. We’re on a mission to reduce cognitive load on developers, minimize configuration drift and mismanagement, and improve the developer experience. Want to join us as a contributor? Read the official announcement to learn more. Or check us out on GitHub!

Last week we released score-spec and I asked a few communities for feedback on how you manage configuration between multiple environments and a lot of you (thanks!) came up with some answers and more questions. Here I wanted to list the pros and cons, in my humble opinion, of the top approaches suggested. Feel free to add yours as well!