docs: Update CHANGELOG.md through version 0.3.0

[karfau]

Only referencing #62 for further discussions.

[brodybits]

In short, info about regressions and most of the info from issue #62 should be included here.

I think some more info about xmldom vs xmldom-alpha as discussed in issues #7 & #62 should be clarified in CHANGELOG.md as well.

I did add the bug label to this. Thanks again!

[brodybits]

What do you think?

👍 (sorry to say, since these updates to CHANGELOG.md do look like a step in the right direction)

[karfau]

Just realized that this is a PR, not an issue. My plan is to continue on this. So I'm just marking it as a draft for now.

[karfau]

From my point of view this is done, as far as already published versions are concerned.

I would suggest to introduce (something like) https://github.com/CookPete/auto-changelog to make it easy to update the CHANGELOG in the future.

This is what it could look like with minimal configuration and manual tweaks:
karfau/xmldom@karfau:patch-1...experiment-auto-changelog

I can take care of it directly after this PR, so it can already be applied when releasing 0.4.0

[brodybits]

I am reviewing this now, my apologies for the delay.

+1 for automating the change log, with some questions coming up

[brodybits]

I left some nits & minor suggestions. In general:

• I would favor keeping present-tense verbs
• I would avoid parens in the version section headers, to keep difference from generated anchors as minimal as possible (I hope we will never have to deal with xmldom vs xmldom-alpha packages again)

[brodybits]

I have never seen auto-changelog before but am starting to like it. I had seen "conventional commits" before in conventionalcommits.org, with a different tool for updating the changelog and maybe for updating the package version. But it looks like these tools should be able to work together, at least in theory.

This is what it could look like with minimal configuration and manual tweaks:
karfau/xmldom@karfau:patch-1...experiment-auto-changelog

I would probably favor putting this into a PR, which should be easier to review and comment on.

As I said before, I generally have not listed devDependencies and test updates in the change logs, open for discussion.

[karfau]

Thx for the review.

I completely removed the notion of xmldom vs xmldom-alpha packages from the headers and added that information just below the publish date.

I converted everything (including older entries) to present tense.

Also made sure the order is always consistent without any empty lines between them

• BREAKING
• POSSIBLY BREAKING
• others

For versions 0.1.25 and 0.1.26 I only added the information we know, and not "Various bugfixes". They have been released on the same day as 0.1.27, so I don't think a lot happened and I don't care enough about those old versions to try and trace the details.

[karfau]

I would probably favor putting this into a PR, which should be easier to review and comment on.

Yes, I just didn't want to invest to much time into it, since I will need to rebase it etc and some details still have to be discussed. I also think it shouldn't block the release of 0.4.0 but it would be nice to already include.

I think the tool just helps to list everything and then it's up to the person publishing the package to decide what information to keep.

[karfau]

Please feel free to merge when you think it's ready.

[brodybits]

I took the liberty to rename this PR (2x) and left what are mostly nits.

One more nit: It looks like we are missing information before version 0.1.18.

I discovered that there is a version 0.1.17 on npm but not in the git history. This would probably be around 2013 or 2014. They may have published 0.1.17 from a special branch or tag in the original repository.

I would probably favor adding a note that details are unknown for versions before 0.1.18.

@karfau I think you should be able to merge this no problem, since it would not be part of a release tag (as a squash commit, please).

[brodybits]

Subjective: I am torn at this point whether to refer to this repo as a "fork" or as a new project location.

Assuming we continue to publish into the same xmldom package on npm, I would not really favor calling this a "fork".

OTOH if we would start publishing this as multiple packages in the @xmldom namespace on npm, which I had already reserved as an org (see issue #54), then I think "fork" would be appropriate.

[karfau]

what about replacing this fork with<https://github.com/xmldom/xmldom> so it stays correct even if it should ever move somewhere else. (Already applied that.)

I think "the announcement of the fork" is still the correct wording for describing what happened back then.

[brodybits]

nit:

Suggested change

	The new maintainers did not invest time to understand changes that led to the last `xmldom` version [`0.1.27`](#0127) published by the original maintainer, but consider it the basis for their work.
	The new maintainer did not invest time to understand changes that led to the last `xmldom` version [`0.1.27`](#0127) published by the original maintainer, but consider it the basis for their work.

the "did not invest time" part is very direct, and unfortunately accurate (perfectly accurate) as well

[brodybits]

or to "turn the knife" on me:

Suggested change

	The new maintainers did not invest time to understand changes that led to the last `xmldom` version [`0.1.27`](#0127) published by the original maintainer, but consider it the basis for their work.
	The new maintainer @brodybits did not invest time to understand changes that led to the last `xmldom` version [`0.1.27`](#0127) published by the original maintainer, but consider it the basis for their work.

[karfau]

Well not anybody of the "new maintainers" (which I consider to be the new xmldom org + contributors) took the time to do that, So I would leave the sentence as is.

And in case anybody takes the time, the sentence can be removed.

[brodybits]

This is what it could look like with minimal configuration and manual tweaks:
karfau/xmldom@karfau:patch-1...experiment-auto-changelog

I would probably favor putting this into a PR

[...]

I also think it shouldn't block the release of 0.4.0 but it would be nice to already include.

I think the tool just helps to list everything and then it's up to the person publishing the package to decide what information to keep.

That makes sense to me.

Maybe a draft PR, that I could use as a starting point for the release of 0.4.0, would make sense. Or maybe not.

It may be ideal to set this up to make npm releases from GitHub actions, someday in the future.