I'm a web developer using Laravel (PHP) and Vue.js. From Girona, Catalonia.
I'm always asking `how does this work?`
I'm always saying `never stop learning.`
There's a thing I don't understand, why you can simply use the first approach which is actually fixing the bug and releasing a minor version like 2.0.1? I think everyone using your framework should have it since I consider it a bug 🤔
Really good question. So how all frameworks work is that at a macro level you have two parts of the application.
Code that runs on the application and loads in the framework pieces
Code that runs inside the package and supplies 99% of the functionality of the framework.
With number 1, it's hard to make changes here that are not breaking changes because it requires a manual adjustment to the code section. it's not something that upgrading the package can handle because its not inside the package.
With number 2, any code changes like this would simply be fixed with a minor release like you said.
This specific section of code is the category of number 1.
Also there is a small chance that packages were created with the notion that some providers are booting before all are registering. The framework is young so I'm currently aware of all packages being built but once it has a large scale repositories of packages then it would be a breaking change because now all providers are registered before booting which could possibly change how some packages function.
The framework is young enough that this solution works for now.
I'm a web developer using Laravel (PHP) and Vue.js. From Girona, Catalonia.
I'm always asking `how does this work?`
I'm always saying `never stop learning.`
Congratulations with the framework! 🎉
There's a thing I don't understand, why you can simply use the first approach which is actually fixing the bug and releasing a minor version like 2.0.1? I think everyone using your framework should have it since I consider it a bug 🤔
Really good question. So how all frameworks work is that at a macro level you have two parts of the application.
With number 1, it's hard to make changes here that are not breaking changes because it requires a manual adjustment to the code section. it's not something that upgrading the package can handle because its not inside the package.
With number 2, any code changes like this would simply be fixed with a minor release like you said.
This specific section of code is the category of number 1.
Also there is a small chance that packages were created with the notion that some providers are booting before all are registering. The framework is young so I'm currently aware of all packages being built but once it has a large scale repositories of packages then it would be a breaking change because now all providers are registered before booting which could possibly change how some packages function.
The framework is young enough that this solution works for now.
Does that answer the question?
Absolutely! Thank you for clarifying this out 🙂