-
-
Notifications
You must be signed in to change notification settings - Fork 194
Announcement: Maintainers Needed #252
Comments
Not looking to maintain, sadly - but I'm a bit torn here. To move to pkger a this point, would be to move from a fairly stable looking tool that's on v2 that works very well to a tool that is currently v0.12 and describes itself as "hopefully" a replacement for packr. If it's only hopefully, I wouldn't want to move yet. Should I? I also don't really want to be using a tool that might soon be abandoned in favour of this one. Hopefully someone can maintain this for those people more heavily invested in packr, but right now I'm not sure what to pick for new projects either because of the above. It seems the choice is either stable but potentially abandoned tool, or new and potentially buggier tool that might change that is maintained. |
That choice is yours, no one is forcing you to move. It's "potentially" a replacement in that you can potentially replace Packr with it. I have stated that I believe Pkger is the way forward, and that I will be focusing on that instead of PackI have no plans to abandon Pkger anytime soon. It's API is based on the Standard Library, so I don't see the API changing much either. Overall it's a much more stable package than Packr. Again, the choice is yours to make. |
Appreciate the swift response Mark. That's good to hear, I'll explain why I've worded it like that though. I don't mean for this to seem like an attack or anything like that, just confusion. I've said "hopefully" just because that's the exact word used in the README for Pkger. There's also that it's the "proposed replacement" in the GitHub description. None of this is actually an issue though if Packr is still going to be maintained. It seem(s|ed) like Packr is or will be abandoned though just because of the way this issue's original post is worded. You say you will stop being a maintainer of it, and that you're looking for maintainers so that people using it aren't left out in the cold. That to me sounds like it could end up being abandoned. I suppose the real question is, whilst you're developing Pkger, is Packr going to remain maintained, and for some window of time after that? It's just that it'd be good to know what the future for both really is, as none of it seems very certain right now. That's what makes that choice a bit more difficult. |
As you may or may not know, I recently announced a replace for Packr, github.com/markbates/pkger.
https://blog.gobuffalo.io/introducing-pkger-static-file-embedding-in-go-1ce76dc79c65
I believe that Pkger is the better solution for static file embedding. With that belief, I will stop being a maintainer of Packr.
I know that many projects use Packr, including Buffalo - which will be moving to Pkger, so I am looking for new maintainers to take over Packr and give it the love it so badly needs so those who still use Packr, aren't left out in the cold.
I highly encourage everyone to try Pkger and eventually migrate to it.
Thank you.
The text was updated successfully, but these errors were encountered: