Scope $destroy issue in 0.2.18

[pitAlex]

Prior to this version when leaving a state, $scope $destroy was called first then the $scope of the new state was made then $stateChangeSuccess was called. Now I see order change completely: first the new state's $scope is made then $stateChangeSuccess is called then $scope $destroy is called on the previous state. Is this part of the new changes? Because its messing up the way I handle some elements design between states.

[christopherthielen]

Fixed in 84fd412

I recommend using ver 0.2.15 until 0.2.19 is released, if the behavior in 0.2.18 is a problem for you.

[dmitry-dedukhin]

Could 0.2.19 be released sooner than usually?
This bug breaks many cases.
For example, if somebody doing some cleanup in services on scope destroy, then at the moment the new data (which was set in service on new scope init) could be cleaned up!

[christopherthielen]

@dmitry-dedukhin I recommend using 0.2.15 (the release prior to the one where this bug was introduced) until 0.2.19 is released.

[dmitry-dedukhin]

@christopherthielen I've updated from 0.2.15 a month ago.
And as far as I remember this update was caused by two $stateChangeStart events bug in 0.2.15. This was critical for me so reverting is not an option...

[phazei]

Is there even going to be a 0.2.19? It's a pretty bad state to leave the 0.2.x branch in... :(

[christopherthielen]

There will be a 0.2.19. I can only do so much in my spare time, sorry.