Why don't you choose to introduce BC breaks with BOX 4.4.0

[llaville]

Hello @theofidry

I'm sorry to said that, but I was first happy to see the new release 4.4.0 after months, and now I'm sad to see so BC breaks.

I regret that you don't follows semantic versioning and choose 4.4.0 rather than 5.0.0 with such changes !

[theofidry]

Hi @llaville, which BC issue did you run into? The very vast majority of the changes released are quite internal so it should not affect you.

[llaville]

Well, after update my https://github.com/llaville/box-manifest project, I was able to run the box:compile command (suppose to be a wrapper around official BOX v4 compile command.
See the issue llaville/box-manifest#9 I've opened to remind it !

Just a reminder, because BOX Manifest live is last days.
Even if I've love to contribute to this cool feature, and learn a lot (Symfony Runtime PHAR, Fidry Console and how to wrap it, and much more ...), this project gave me too much trouble to maintains and be synchronized with offficial BOX, that it will be stopped after bugfix upcoming release 3.5.1 (that will support latest 4.3.8 BOX version).

About BC issue, even if you marked is as private now, PharInfo BOX component was previously public (under another namespace https://github.com/box-project/box/blob/4.3.8/src/PharInfo/PharInfo.php)

Such kind of changes, is for me a BC break and need a MAJOR version when you follows semantic versioning rules.

When you've doubt about next version to apply on a project, I suggest you to give a try on this cool tool that help on decisions => https://github.com/tomzx/php-semver-checker

[theofidry]

About BC issue, even if you marked is as private now, PharInfo BOX component was previously public (under another namespace https://github.com/box-project/box/blob/4.3.8/src/PharInfo/PharInfo.php)

Ha I see. My mistake this class was definitely meant to be private I forgot about that change (it was a few months ago...).

If it is the only problem though it is one I can fix with ease.

Just a reminder, because BOX Manifest live is last days.
Even if I've love to contribute to this cool feature, and learn a lot (Symfony Runtime PHAR, Fidry Console and how to wrap it, and much more ...), this project gave me too much trouble to maintains and be synchronized with offficial BOX, that it will be stopped after bugfix upcoming release 3.5.1 (that will support latest 4.3.8 BOX version).

That is entirely fair. It's really not an easy thing to do especially for 1. a tool like Box 2. a project like this one where most of the core is a private API, since at least for now most it is really more meant to be used as a black box distributed tool rather than a library.

When you've doubt about next version to apply on a project, I suggest you to give a try on this cool tool that help on decisions => https://github.com/tomzx/php-semver-checker

I had no doubt about it :) If there was any BC break it was a mistake. I do have in mind Box5 but it will be more things than internal refactoring stuff.

[llaville]

I do have in mind Box5 but it will be more things than internal refactoring stuff.

For BOX v5, I recommand you to think about a new architecture based around two projects :

• one library that will include all API public that may be reused by the community if you want to have a real BOX eco-system
• one presentation layer that will allow to have a simple CLI application that wraps your core code (library)

[theofidry]

It's definitely been in the back of my mind, same for PHP-Scoper, but not certain it makes it to v5. There is still quite a few moving pieces.

Also need to weight in a mono-repo approach, a kinda like it is done with the requirement checker.

But they all are relatively expensive changes, and I think there is higher priority ones such as #580.