-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long term plans and support #52
Comments
i'm not @ungoldman (obviously) but my personal experience w/ projects that he shepherds is corroborated by the tags you see on open issues in this repository (ie: even though the code is in 'maintenance mode', PRs are usually welcome.). that said, opening up a discussion first to think through vision/scope is always appreciated. my off the cuff opinion is that modernizing and improving the code here and possibly augmenting it w/ additional helpers maintained somewhere else for more esoteric workflows would be preferable to forking, but the latter isn't necessarily problematic if you attribute what you're building on appropriately. just my two cents from the peanut gallery though. ❤️ |
Hi @rgembalik
good luck and happy coding ✌️ |
I should mention the API for this project has been stable for a long time and it's still seeing enough use in the wild (85k+ downloads/month) that I'm not keen on drastically changing it since it's mostly a basic support package for other larger open source projects. But if you're interested in contributing incremental backwards compatible changes that work for your use case, PRs welcome |
@ungoldman Thank you very much for your response and understanding. The reason I asked in the first place was that the package seems to be focused on CLI/node use only, which is perfectly understandable, but I was afraid my suggestions may go way beyond the original vision for the package. I am pretty sure I'd be able to do it with backward-compatibility in terms of API (input->output in CLI and module) but it would be a rewrite anyway just so that I can incorporate a typed approach for ease of use in scripting API on the browser side. Let me sleep on it, and I'll see if I can draft a proposal for v4 that would include the same API. If you are fine with becoming a "Universal Change log" and not only a "Change log parser for node." then I'd happily introduce the refactor here as I see more value for the community in adding it into a package that's already popular. |
@ungoldman Here's a short update on my progress so far:
I consider the first issue a breaking change, although the 3.0.1 version wasn't the expected behaviour all the time from my perspective. The second issue is not technically BC, but still worth solving to keep the best possible memory utilization in mind. Once I have these two resolved, I'll be happy to publish a PR with the cleaned PoC. |
Hi @rgembalik Thank you for spending time on this. I do want to emphasize again something I said earlier:
A pull request with a full rewrite of the package is a drastic change. While I appreciate your enthusiasm in improving this package, a rewrite in a fork might be a better starting point. |
Understood. I took it a bit differently, i.e. it's ok if we maintain backwards compatibility, but that's probably my overenthusiastic approach ;) But that's one of the reasons I posted an update above - I wanted to know how you feel about my direction, so I am happy I did that. In such a case, I'll probably start a new package ( |
Good luck and happy coding. I hope your project goes well. If you find some small things that are easy to patch here your contributions are welcome :) |
Hey,
I've got a few questions regarding the future of this package:
If these don't align with the package vision, that's fine, but I'd love to have at least consent to reuse some of this code for my own public package.
The text was updated successfully, but these errors were encountered: