Prepare release 2.0 #90

Jean85 · 2017-11-03T09:41:49Z

DO NOT MERGE BEFORE #87!! Also wait for Symfony 4.0 release, so it will be tested in Travis CI.

This follows #89:

drop support for Symfony 2.x
support Symfony 4.x
require PHP 7.1+
thus, will leverage all the new language features (return, scalar and nullable types to start with)
wait for the release of Symfony 4, to test this in CI

…eErrorEvent

… bundle

(cherry picked from commit 30fab0c)

ruudk · 2017-11-24T11:06:44Z

I'm trying to upgrade my project to SF v4.0.0-RC1 but it fails because this bundle is ready for SF 4. It would be great if we could tag the 2.0-alpha1 release or something. That way, I can use this to test if the SF 4 stuff actually works :)

It will greatly help people that are already testing SF 4 and are preparing for when it's officially released.

Jean85 · 2017-11-24T11:08:41Z

@ruudk maybe you can composer require sentry/sentry-symfony dev-prepare-release-2.0?

[EDIT] Also, it would be great if you could post your feedback here, I don't have an upgradable, real app to use as a test... So a 👍 from a real app with SF 4 would be greatly appreciated! 😄

ruudk · 2017-11-24T11:11:18Z

@Jean85 Yeah, silly, I was just trying that :) Tx!

Jean85 · 2017-11-28T15:16:17Z

@ruudk have you encountered any issues with Symfony 4? Is error reporting working well?

ruudk · 2017-11-28T15:59:12Z

Well, I didn't upgrade to SF 4 yet because many deps are blocking it :( Had to wait for a couple of packages (behat for example(

(cherry picked from commit c93be40)

Jean85 · 2017-12-04T17:12:01Z

Finally cleaned this up!
The bundle should be SF4 ready, awaiting reviews!

dcramer

i didnt actually QA the changes, but the majority of it looks super straight forward

(sorry for the delay!)

mitsuhiko · 2017-12-06T23:46:57Z

I'm guess this looks good but I do wonder if we really can no longer support VERSION. This kinda defeats the purpose of this constant if it changes over to a method, no?

ruudk · 2017-12-07T08:32:15Z

src/SentryBundle.php

+    {
+        return PrettyVersions::getVersion('sentry/sentry-symfony')
+            ->getPrettyVersion();
+    }


Not really a fan that this now requires jean85/pretty-package-versions that in turn requires ocramius/package-versions.

Is this really that important? Can't we just automate this with a tag-and-release script?

Yes it's really helpful. In the past we made mistakes with some releases, because it's pretty easy to forget to change that constant, and it's even easier to mess with that during merges.

ocramius/package-versions + PrettyVersions is 4 classes tops, and it's perfectly lightweight, since it operates during composer install: it pre-populates an array with all the versions, so at runtime it is very fast.

I'm currently using it twice, because I use the PrettyVersions to append the application version to Sentry's reports; I think I'll append a tutorial about that in the readme.

Obviously the previous answer is for @stayallive too, since it raised the same concern.

I would like to veto this change. Also because it breaks the VERSION constant which people might already use. Can we instead just have a release script?

@jan-auer can hook up our release bot with this so it's automated when tags are pushed.

Where does this get released? Just composer or something else, too?

@mitsuhiko this is obviously to be released as a new major version, so BC should be allowed (if we want to follow semver, and IMHO we should).

@jan-auer yes this bundle is be released on Packagist/Composer only.

I'm not sure how the bot should help there. As far as I know, packagist just requires you to check in a composer.json in the root folder and does the rest automatically, no?

@Jean85 so we recently made this small GitHub bot that triggers releases based on tags. It requires all status checks (e.g. Travis, AppVeyor, CodeCov, ...) to succeed before that. Essentially enables the following workflow: tag, push, wait, done. This is especially useful for releases that would otherwise require us to do multiple manual steps.

@jan-auer the issue here is that if you tag, you have basically already released it. Packagist picks up tags as releases, so it's already too late, especially if you made a mistake.

That's a big issue here because the dispute is about the VERSION constant, which is used to send that info to Sentry as an info on each event, and forgetting to update it so has some real consequences.

As an example, tt already happened in 1.0.1 and 0.8.4 up to 0.8..6, so I'm not talking hypotetically.

stayallive

Looks good, missing some return type (for consistency sake) but very clean overall.

I would like to add a +1 for not removing the VERSION constant since it's so simple and fast and remove a few dependencies. IMHO error tracking should be lean and mean.

stayallive · 2017-12-07T08:51:47Z

src/EventListener/ExceptionListener.php

     */
-    public function onConsoleException(ConsoleExceptionEvent $event)
+    public function onConsoleException(ConsoleErrorEvent $event)


You are missing the void return type here (saying since you added it everywhere).

stayallive · 2017-12-07T08:52:09Z

src/EventListener/ExceptionListener.php

@@ -142,7 +143,7 @@ public function onConsoleException(ConsoleExceptionEvent $event)
        $this->client->captureException($exception, $data);
    }

-    protected function shouldExceptionCaptureBeSkipped(\Exception $exception)
+    protected function shouldExceptionCaptureBeSkipped(\Throwable $exception)


Missing return type bool.

stayallive · 2017-12-07T08:52:35Z

src/EventListener/SentryExceptionListenerInterface.php

     */
-    public function onConsoleException(ConsoleExceptionEvent $event);
+    public function onConsoleException(ConsoleErrorEvent $event);


Missing void return type.

Jean85 · 2017-12-07T15:07:44Z

I've fixed the missing return types reported by @stayallive; for the drop of the VERSION constant:

@mitsuhiko you where concerned about the change from a constant; the new method is static, so it can be called anywhere without an instance of the class, same as the constant
@stayallive and @ruudk you were concerned about the additional dependencies; I've responded in this Prepare release 2.0 #90 (comment); note also that they are very lightweight, no runtime overhead.

I'll wait to next week before merging this, so we can continue the discussion if needed.

mitsuhiko · 2017-12-07T15:09:20Z

@Jean85 I don't care about it being a static or non static method but that it's no longer a constant. The entire point of that constant is that you can compare it. This means that from one version to another we changed the way to check for the version. That's less than ideal for users.

Jean85 · 2017-12-07T15:25:26Z

@mitsuhiko on the end-user side, it's the same:

// before
$expectedVersion = '1.0';
SentryBundle::VERSION === $expectedVersion;
// after
SentryBundle::getVersion() === $expectedVersion;

PrettyVersion is based on Git commit, branch and tags, so its output will be a lot more precise than before:

if it's a tagged version, it will be the tag, i.e. 2.0.0
if it's from a branch, it will be the branch name + the SHA of the commit, i.e. dev-branchname@123456abcdef
if it's from a branch that's listed in the branch-alias section of our composer.json (see here) it will use that aliases, i.e. 2.0.x-dev@123456abcdef

This IMHO will mean more precise info on the user side, and a reduced effort on the maintaner (our) side.

ruudk · 2017-12-07T15:36:20Z

@Jean85 This requires the present of a .git directory orcomposer.json on the system. We package our app releases, and strip out all non relevant stuff from it.
The Sentry version is totally not important in my Sentry errors.

Jean85 · 2017-12-07T15:45:32Z

@ruudk the presence of the composer.json and the .git dir is needed only during the composer install phase, that already requires that by definition. You can remove those later without consequences, since the version infos are written down inside the PackageVersions\Versions class in the vendor folder as a post-install step.

[EDIT] Also, the Sentry client/bundle versions are highly relevant when reporting bugs to us, otherwise it's really hard to track those down!

I would like also to add that ocramius/package-versions is a pretty solid package which is reaching 4M downloads, and it's already a dependency of DoctrineORM and ocramius/proxy-manager, which are 2 pretty common packages used with nearly all Symfony full stack installation, so probably it's already in there in the majority of projects that use this bundle.

ruudk · 2017-12-07T16:01:13Z

Ok, that is clever :)

kermorgant · 2017-12-11T16:19:37Z

Hello,

I'm not really sure whether the error comes from my setup or not but here is what I got on a sf4 app recently upgraded from beta :

Uncaught Symfony\Component\Debug\Exception\FatalThrowableError: Type error: Argument 1 passed to Sentry\SentryBundle\EventListener\ExceptionListener::onConsoleException() must be an instance of Symfony\Component\Console\Event\ConsoleErrorEvent, instance of Symfony\Component\Console\Event\ConsoleExceptionEvent given

Jean85 · 2017-12-11T17:10:00Z

Umh that's pretty strange, ConsoleExceptionEvent should be deprecated in 3.3 and removed in 3.4: http://api.symfony.com/3.4/Symfony/Component/Console/Event/ConsoleExceptionEvent.html

@kermorgant are you sure you were using symfony/console 4.0?

kermorgant · 2017-12-11T19:40:34Z

...sorry for that, it was indeed version 3.3. now upgraded to 4.0.1
So for what it's worth, it's now running and got my first exception logged as it should

ruudk · 2017-12-11T19:48:16Z

that means that we should require symfony/console ~4.0 right?

Jean85 · 2017-12-12T08:31:17Z

@ruudk if you require symfony/symfony ~4.0 you already have it. The issue then is that this PR is not compatible with ~3.0 too as I would like.

I will try to fix that.

ruudk · 2017-12-12T08:34:23Z

I was confused by @kermorgant because he said he got the error while using 3.3 and this PR required symfony/console ~3.3 || ~4.0. If it works correctly with 3.3 then it's good.

stayallive

No Symfony man, but eyeballing (read: did not test on my machine) this looks good 👍

You should fix Travis though before merging 😉

Jean85 · 2017-12-12T13:51:58Z

Thanks @stayallive, now I've fixed it!

I'll merge this now, and open a new PR to add some more testing.

ruudk · 2017-12-12T14:28:37Z

Congrats on this release 🎉 Great work everybody 🙌

This is possible since the constraint was introduced in d772535 (#90), but since we no longer use the ExceptionHandler, we're no longer bound to use the ConsoleErrorEvent.

Jean85 added 9 commits November 3, 2017 09:25

Bump requirements in composer.json

c578ffe

Update Travis to reflect the new version contraints

01575b5

Fix typo in composer.json

4f2b021

Add types where possibile; require symfony/console 3.3+ due to Consol…

d772535

…eErrorEvent

Use jean85/pretty-package-versions to show the correct version of the…

0eef564

… bundle

Update changelog

7181a2a

Fix unit test

482be86

Refactor and fix onConsoleException

fe8ff7b

Increase and fix PHPStan checks

275ce20

Jean85 added this to the Release 2.0 milestone Nov 3, 2017

Jean85 self-assigned this Nov 3, 2017

Jean85 requested a review from dcramer November 3, 2017 09:41

Jean85 added 5 commits November 3, 2017 10:50

Fix code style

6c365c5

Mark version as 1.0 and tag it

ae712c4

Mark correct bundle dev versions

30fab0c

Mark correct bundle dev versions

fbdca2f

(cherry picked from commit 30fab0c)

Merge from releases/1.0

040d2be

Jean85 mentioned this pull request Nov 22, 2017

Deprecation messages of ConsoleEvents::EXCEPTION when running console commands. #95

Closed

Make client service public

bbc2c9b

Jean85 changed the title ~~[WIP] Prepare release 2.0~~ Prepare release 2.0 Dec 4, 2017

Jean85 added 5 commits December 4, 2017 15:25

Define a public alias in test for the listener

2e65e76

Fix listener tests

9aff0de

Mark explicitly as public test aliases

16519d2

Fix CS; update PHPStan; put commands in composer.json

faf4c4e

Fix or ignore PHPStan errors

c270dbd

(cherry picked from commit c93be40)

Jean85 force-pushed the prepare-release-2.0 branch from 19bf1bd to 0e5fd35 Compare December 4, 2017 16:27

dcramer approved these changes Dec 6, 2017

View reviewed changes

ruudk reviewed Dec 7, 2017

View reviewed changes

stayallive approved these changes Dec 7, 2017

View reviewed changes

Add missing return types

132b469

Add last missing return type

4999bcd

Add BC trick to avoid issues with Symfony 3.x

9681cb6

stayallive approved these changes Dec 12, 2017

View reviewed changes

Fix PHPStan errors

3aaa5af

Jean85 force-pushed the prepare-release-2.0 branch from 3dd9eb5 to 3aaa5af Compare December 12, 2017 13:34

Jean85 merged commit 3e94025 into master Dec 12, 2017

Jean85 deleted the prepare-release-2.0 branch December 12, 2017 13:52

Jean85 added a commit that referenced this pull request Feb 25, 2019

Allow symfony/console as low as 3.0

ae50b7e

This is possible since the constraint was introduced in d772535 (#90), but since we no longer use the ExceptionHandler, we're no longer bound to use the ConsoleErrorEvent.

Jean85 added a commit that referenced this pull request Feb 26, 2019

Allow symfony/console as low as 3.0

1b6b222

This is possible since the constraint was introduced in d772535 (#90), but since we no longer use the ExceptionHandler, we're no longer bound to use the ConsoleErrorEvent.

Prepare release 2.0 #90

Prepare release 2.0 #90

Uh oh!

Conversation

Jean85 commented Nov 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ruudk commented Nov 24, 2017

Uh oh!

Jean85 commented Nov 24, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ruudk commented Nov 24, 2017

Uh oh!

Jean85 commented Nov 28, 2017

Uh oh!

ruudk commented Nov 28, 2017

Uh oh!

Jean85 commented Dec 4, 2017

Uh oh!

dcramer left a comment

Choose a reason for hiding this comment

Uh oh!

mitsuhiko commented Dec 6, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Jean85 Dec 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stayallive left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Jean85 commented Dec 7, 2017

Uh oh!

mitsuhiko commented Dec 7, 2017

Uh oh!

Jean85 commented Dec 7, 2017

Uh oh!

ruudk commented Dec 7, 2017

Uh oh!

Jean85 commented Dec 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ruudk commented Dec 7, 2017

Uh oh!

kermorgant commented Dec 11, 2017

Uh oh!

Jean85 commented Dec 11, 2017

Uh oh!

kermorgant commented Dec 11, 2017

Uh oh!

ruudk commented Dec 11, 2017

Uh oh!

Jean85 commented Dec 12, 2017

Uh oh!

ruudk commented Dec 12, 2017

Uh oh!

stayallive left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Jean85 commented Nov 3, 2017 •

edited

Loading

Jean85 commented Nov 24, 2017 •

edited

Loading

Jean85 Dec 7, 2017 •

edited

Loading

Jean85 commented Dec 7, 2017 •

edited

Loading

stayallive left a comment •

edited

Loading