Long term plans and support about changelog-parser HOT 8 CLOSED

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. ❤️

from changelog-parser.

@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.

from changelog-parser.

@ungoldman Here's a short update on my progress so far:

• I managed to replicate the base API with ts->esm/cjs-compiled package
• Core logic is the same, but is structured in a bit different way internally
• I've two outstanding issues left for now:
  • EOL does not behave the same as the 3.0.1 package unless the file being read has the same line endings as require('os').EOL.
  • I haven't touched on file-streaming yet. For now, I'm still reading files synchronously. While it's not an optimized solution, it shouldn't influence the results. The complexity of the memory usage still stays the same, as within the original package, the result contains the entire source in the output structure.
• In return, the package is working well on browsers and the new code utilizes yargs and a dedicated parser class, which extends the possibilities of parseChangelog method with the ability to change parsing patterns and treat lines one by one.

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.

from changelog-parser.

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 (changelog-tools or sth), giving proper credentials to this source code. In the end, it may simplify a couple of matters if I don't try to maintain compatibility.

from changelog-parser.

Hi @rgembalik

1. This package is not under active development, but as @jgravois mentioned, PRs are welcome for bug fixes and improvements
2. There are no plans for updates at this time, as all the writers/maintainers have moved on to other projects (myself included)
3. You're welcome to fork as long as you keep the license and attribution, but with the amount of changes you're suggesting, I'd recommend starting fresh with a rewrite. If I were to work seriously on this project again that's what I would do. The code is very dated and it could use some serious restructuring.

good luck and happy coding ✌️

from changelog-parser.

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

from changelog-parser.

Hi @rgembalik

Thank you for spending time on this. I do want to emphasize again something I said earlier:

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

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.

from changelog-parser.

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 :)

from changelog-parser.