ulid organization
alizain opened this issue · comments
Hey! I'm thinking of creating a ulid org, with the spec, and a couple reference implementations. That would mean breaking out the current repo into a spec repo, and a JS implementation repo. Would you be interested in merging with the org for the go implementation?
👍 from my side. What's your take @peterbourgon?
Hmm, I'm not sure it makes sense to move a bunch of different language implementations of something into a single, new GitHub org. Why not just link to the implementations where they exist?
The first is golang itself - some users have asked for a self-contained binary and the easiest way to support that is to write it in go, which is why you’re the first implementation I’m reaching out to.
Sorry, I don't understand what this means, in the context of my question...
The second is consistency. I updated the spec to allow for monotonically increasing ULIDs, and simultaneously implemented the change in JS. Similarly, I’d like to be able to guarantee that a subset of all implementations correctly, faithfully, and completely implements the latest spec.
File an issue! :)
I can do that very easily for the JS implementation, because it’s in the repo, but I’d like to be able to do that for the go implementation as well.
Are you proposing to take ownership of this implementation?
@alizain Ping
Sorry for the delayed response, got a bit busy on my side.
Sorry, I don't understand what this means, in the context of my question...
Following on from #13, it would be nice to have an "official" or "blessed" version of ulid that can be brew install'ed. To that end, golang is the natural choice for implementation language, because it compiles to a binary, and is relatively high-level. Instead of writing a new implementation of ulid in golang, the first thought I had was to use this implementation instead. To make it all a little nicer and easier to manage, creating a GitHub organization followed naturally too.
File an issue! :)
Fair enough :)
Are you proposing to take ownership of this implementation?
Partly. I'm proposing that the maintainers of this repo and myself become maintainers of the proposed org this would be hosted under. I would assist wherever I can to maintain and develop this repo, alongside the javascript implementation, and the actual spec. I would also break out the javascript implementation and spec into separate repos, under the new org.
OK, thanks for the clarification. At the moment, I'm not convinced that a new org needs to be created, nor that this repo needs to be moved, to get any of those benefits: we can easily commit to keeping this implementation in line with a spec, and to publishing versioned commandline tools, without it. But I may change my mind if I dwell on it for a little while. Give me a bit of time.
Take your time :) Thanks for the consideration!