Update changelog.txt

[ff6347]

When the merge of the linted test files is done I will update the changelog and would suggest keeping track of patch changes by bumping the path version to 1.1.1

[trych]

Hang on, now I am confused. Why would we change anything to 1.1.1 now?

[ff6347]

Because we patched something. :-) As we already discussed in several threads I think. I'm totally into using semver and increase the patch number with such changes like changing in nearly every file in the repo from @ to #

[trych]

Ok, but we will not release a 1.1.1 then, right?
Because I think all changes that we do from now on should be released with 2.0.

The last time we discussed semver, I thought we agreed that a version bump only needs to happen when we agree on a release. See the discussion back then.

[trych]

What I mean is, that if we release something, only then we have to decide if the changes according to semver qualify for a x.x.1 bump, for a x.1.x bump or for a 1.x.x bump. But if we are not releasing anything anyways at the moment we also don't need to bump any version numbers, until we finally do the big 2.0 release.

[ff6347]

Well. You know my opinion on that. Even if we don't release we should keep track of changes in the version numbering. So it is easier to identify when something was introduced.

[trych]

Well. You know my opinion on that.

Apparently I did not. 😉

I think to identify when something was introduced we can use git and its PR / commit history.
Bumping the version after every feature that was introduced does not make much sense to me. According to that logic we would have to bump it up one major version with each PR that introduces something that is not backwards compatible (which there will be a few of before our planned 2.0) and then we would have to bump up to 2.0, 3.0, 4.0, 5.0.

Instead I think we should collect all the changes that we do (as we already are) until the next release, put this in the changelog for the one version we release and then decide how to bump according to semver (which would be a major bump in this case, since we introduce backwards incompatibility).

From a user perspective it would be only confusing to have all these new versions in the changelog without ever having them seen released and from a developer perspective we can use git for history.

That's my opinion at least. :)

[ff6347]

According to that logic we would have to bump it up one major version with each PR that introduces something that is not backwards compatible

Yes. actually yes. But I don't mind that much to start a war about it 😄 (closing this and updating the changelog.txt as soon as the linting PR is done).
What incompatible changes did we make?

[trych]

Yes. actually yes.

That's what I am referring to. I don't think that means that you have to bump the version on every PR that introduces backwards incompatibility, but instead that you have to bump the version with every release that introduces backwards compatibility. Only when you do a release you have to check: Ok, what sort of changes were introduced and then you can be like: Oh, these changes here are backwards incompatible, so we have to bump it up one major version.

We have not introduced anything backwards incompatible yet. But according to your logic it would work like this:

1.) You implement the feature, where b.go() is not needed anymore and do a PR. We look at it, this is an backwards incompatible feature, according to semver we have to bump up one major version now. We bump it up to 2.0.0, while all the other features are not ready yet.

2.) Next you implement the feature, where the b is not needed anymore and do a PR. We look at it, this is an backwards incompatible feature, according to semver we have to bump up one major version now. We bump it up to 3.0.0.

3.) Next I implement some feature, where all the b.itemXXX functions are replaced by b.transform() and do a PR. We look at it, this is an backwards incompatible feature, according to semver we have to bump up one major version now. We bump it up to 4.0.0.

Fast forward a few PRs.

4.) We release the all new basil 9.0.0. The user is confused why he hasn't heard of all the previous major releases. ;)

I don't want to start a war either, all I want to say: I think it makes sense to apply semver only on releases and therefore also bump the version number only on releases, and not every time a PR was done to the develop branch. A changelog should always inform the user of the current and past released versions and therefore we should collect all the features that we implement and then when we release apply the semver logic once for that release.

[ff6347]

Yes. Let's keep it that way