Skip to content
This repository has been archived by the owner on Jun 25, 2022. It is now read-only.

Announcement: Maintainers Needed #252

Open
markbates opened this issue Nov 17, 2019 · 3 comments
Open

Announcement: Maintainers Needed #252

markbates opened this issue Nov 17, 2019 · 3 comments

Comments

@markbates
Copy link
Member

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.

@markbates markbates pinned this issue Nov 17, 2019
@seeruk
Copy link

seeruk commented Dec 3, 2019

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.

@markbates
Copy link
Member Author

markbates commented Dec 3, 2019

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.

@seeruk
Copy link

seeruk commented Dec 3, 2019

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants