Comments (8)
It occurred to me that the 1.x branch we are proposing to support Laravel
^5.5 <6.0
will introduce breaking changes in what should be a minor release (following semver). What do you think about release that as 2.x and moving these release to 3.x? The 2.x line will start the new Agent and provide pre-Laravel 6 support (to a reasonable extent) while the 3.x line will move the project features forward and provide Laravel 6+ support. That will prevent surprises for your current users and make it easier to communicate what release to use.
I agree. I will release 3.0 for now, and wait until we make sure 2.x branch work as expected on L5.5 applications.
from elastic-apm-laravel.
I think the removal of Guzzle is a BC for most people. It fixes a specific use case, but I don't see that it was previously reported, so the release notes should probably point out what most people will experience, a need to add a new dependency as part of the upgrade.
The only other thing that comes to mind relates to the jobCollector. If that was present in the previous release, would it not have exhibited the send failures reported in #57 and fixed in #77? It that was not in the previous release, then it should be added as a new feature.
from elastic-apm-laravel.
It occurred to me that the 1.x branch we are proposing to support Laravel ^5.5 <6.0
will introduce breaking changes in what should be a minor release (following semver). What do you think about release that as 2.x and moving these release to 3.x? The 2.x line will start the new Agent and provide pre-Laravel 6 support (to a reasonable extent) while the 3.x line will move the project features forward and provide Laravel 6+ support. That will prevent surprises for your current users and make it easier to communicate what release to use.
from elastic-apm-laravel.
I think the removal of Guzzle is a BC for most people. It fixes a specific use case, but I don't see that it was previously reported, so the release notes should probably point out what most people will experience, a need to add a new dependency as part of the upgrade.
Yes, this is a good point, I will make it part of the release note. Thanks.
The only other thing that comes to mind relates to the jobCollector. If that was present in the previous release, would it not have exhibited the send failures reported in #57 and fixed in #77? It that was not in the previous release, then it should be added as a new feature.
Correct, this is something that we also fixed 👍
from elastic-apm-laravel.
I'm working on what is now the 1.x branch. I may not be able to complete it today unfortunately, but hopefully tomorrow.
from elastic-apm-laravel.
I'm working on what is now the 1.x branch. I may not be able to complete it today unfortunately, but hopefully tomorrow.
You mean 2.x branch right? I will create a 3.0 release for L6 support and 2.0 for L5.5. Latest changes are be available on 2.x branch already.
from elastic-apm-laravel.
Well, yes. It was still named 1.x when I started. I'll get caught up. :)
from elastic-apm-laravel.
v3.0
has been released 🎉
from elastic-apm-laravel.
Related Issues (20)
- Issue with Octane HOT 1
- Use of undefined constant LARAVEL_START - assumed 'LARAVEL_START' (this will throw an Error in a future version of PHP) HOT 3
- Did not collect data from Api routes HOT 1
- Return value of AG\ElasticApmLaravel\ServiceProvider::getAppConfig() must be of the type array, null returned HOT 4
- installation error HOT 2
- installation error HOT 7
- Logs for deprecated parameters
- Apm setup HOT 4
- Laravel 9? HOT 12
- Laravel Octane Support HOT 8
- Standard ELASTIC_APM_ENVIRONMENT value is not used correctly
- Build failing due to failure in the Command collector HOT 3
- Transaction not getting associated with Errors on Elastic Cloud APM HOT 1
- Send only Transactions associated with Exceptions to APM Server HOT 1
- Application ENV not picked up by agent HOT 1
- Need to include latest version of nipwaayoni/elastic-apm-php-agent HOT 2
- Jobs not tracked HOT 8
- AG\ElasticApmLaravel\Collectors\EventDataCollector::shouldIgnoreTransaction(): Argument #1 ($transaction_name) must be of type string, HOT 6
- Laravel Telescope Support HOT 1
- Is there a reason that this agent doesn't allow collecting stacktraces? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from elastic-apm-laravel.