Bump version to 5.0.0 and Fixed .gitignore

[Progi1984]

No description provided.

[PierreRambaud]

What is the reason to update to a major version? 🤔

[Progi1984]

@PierreRambaud Because #35 has removed some compatibility (min 1.7.0 => 1.7.7)

[matks]

@Progi1984 I went into all PRs not release yet to add either "Bug" or "Improvement" label so release-drafter should display a pretty changelog 😄

[PierreRambaud]

@Progi1984 I went into all PRs not release yet to add either "Bug" or "Improvement" label so release-drafter should display a pretty changelog

DO IT: https://github.com/PrestaShop/ps_facetedsearch/releases ❤️

too fast

[PierreRambaud]

@PierreRambaud Because #35 has removed some compatibility (min 1.7.0 => 1.7.7)

But changing the compatibility does not break the public API.

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner

We change our compatibility range, but we don't break anything in the code 🤔

[matks]

@Progi1984 I went into all PRs not release yet to add either "Bug" or "Improvement" label so release-drafter should display a pretty changelog

DO IT: https://github.com/PrestaShop/ps_facetedsearch/releases ❤️

@PierreRambaud Because #35 has removed some compatibility (min 1.7.0 => 1.7.7)

But changing the compatibility does not break the public API.

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner

We change our compatibility range, but we don't break anything in the code 🤔

Yes and no. If I am running the module on PS 1.7.5 and I upgrade to the new version, I expect a patch/minor version to still run on PS 1.7.5 .

However since we can control the compatibility range, maybe here it's OK 🤔 I dont know

[atomiix]

@Progi1984 Why this condition if min compability is >= 1.7.7.0 then? https://github.com/PrestaShop/blockreassurance/pull/35/files#diff-9710de17450c42ac02b80aee66949713R153

[PierreRambaud]

@Progi1984 I went into all PRs not release yet to add either "Bug" or "Improvement" label so release-drafter should display a pretty changelog

DO IT: https://github.com/PrestaShop/ps_facetedsearch/releases heart

@PierreRambaud Because #35 has removed some compatibility (min 1.7.0 => 1.7.7)

But changing the compatibility does not break the public API.

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner

We change our compatibility range, but we don't break anything in the code thinking

Yes and no. If I am running the module on PS 1.7.5 and I upgrade to the new version, I expect a patch/minor version to still run on PS 1.7.5 .

However since we can control the compatibility range, maybe here it's OK I dont know

There is a compatibility range check in the BO when notice the user for a new update 🤔
Plus, semver is talking about the code itself, not dependencies. Otherwise, we must create a new major each time we are increasing the PHP version range, or updating a dependency as we did for PHP 7.3 in the Core

[matks]

Plus, semver is talking about the code itself, not dependencies. Otherwise, we must create a new major each time we are increasing the PHP version range, or updating a dependency as we did for PHP 7.3 in the Core

The definition of Breaking Change is actually not clear. SemVer provides one indirectly, but there is no "standard" definition. Google it, and you'll see multiple people discussing it but there is no accurate definition (although everybody agrees on the concept).

From some users point of view, if I am running the module on PS 1.7.5 and I upgrade to the new version, I expect a patch/minor version to still run on PS 1.7.5 .

This being said, thanks to the compatibility check, here we are fine I think.

[Progi1984]

@PrestaShop/prestashop-core-developers What am I doing for this PR ?

[PierreRambaud]

@Progi1984 We need to clarify what a BC breaks really is.

[Progi1984]

@PierreRambaud Discussion is back here : PrestaShop/docs#607

[matks]

@PierreRambaud Because #35 has removed some compatibility (min 1.7.0 => 1.7.7)

It seems we have not modified $this->ps_versions_compliancy = ['min' => '1.7', 'max' => _PS_VERSION_]; and consequently this is not ackowledged: #47 (comment)