Closed Vad1mo closed 1 year ago
I'm somewhat familiar with gocraft/work
. I've used it for small projects in the past, but I'm by no means an expert.
I'd start by
Also curious in replacing gocraft/work with this due to this primarily https://github.com/gocraft/work/issues/148
Is there anything that could be taken on by outside contributors to help get neoq closer to a 1.0 release?
@elliotcourant @Vad1mo Up until now there have been two parts to my holding off on the 1.0
milestone.
I wanted the freedom to evolve neoq's API in its early stages.
However, I think it's relatively safe to lock neoq's API in place at this point. I like the API and a few others I've talked to have said the same.
Until this point I've primarily held 1.0
off because I wanted the freedom to change the API. But because I'm pretty satisfied with it, that is much less of a reason today than it was 6 months ago.
So with that said, you have my guarantee that the API (i.e. neoq.Neoq
) won't change between now and the 1.0
release.
The other component of my holding out on 1.0
is that I'd like more real world feedback for multiple backends. Primarily, memory
and postgres
, since those are neoq-first implementations. Whereas redis
is simply asynq
with Neoq's API in front of it -- so I'm less interested in redis
feedback because asynq is good, and stable.
Since mentioning neoq in my blog post recently, neoq has gotten a lot more attention and usage. I expect that to turn into more bug reports, questions, and feedback. While I don't have any plans to add new major features before 1.0
, I would be happy to accept some usability feedback and bug reports before then.
So I'd like to to target roughly a month from now so that feedback from new users can be gathered and acted upon.
How does that sound?
Is there anything that could be taken on by outside contributors to help get neoq closer to a 1.0 release?
I'm happy to accept any contributions. Top priority will be fixing any bugs. But I'd also be happy to accept improvements to test coverage, as increased coverage is likely to reveal some low hanging fruit in the bug department.
This sounds excellent, I'm going to start trying to use it in my own projects and we'll see what comes of it. I'm happy to help fix any bugs I do find or in general help contribute upstream!
I'm going to go ahead and close this issue since it's not about neoq functionality. Feel free to open a new issue if you have any more questions.
Hello, for our project Harbor Jobservice I am considering replacing it with neoq. But before jumping into days of code refactoring, I wanted to see if you have any experience of compatibility of those two.