PIXI current versions in the future ?

[jinzo7]

Hello, developers! 

I am wondering about PIXI v.3 or v.4, how much they can live and work on the internet.

Imagine now I start big project on v.3 or v.4. This project should be licensed with little exceptions.

Should I extract the whole code related to PIXI(my view) to be specially maintained over the time?

What is the experience on similar cases?

What is the risk? 



 

[jonforum]

my personal opinion is that pixiGuys make a lot of effort to alert retroCompatibility.

When a code becomes obsolete, your program works but you get alerted that changes are being made.

so the risks are minor, if you work neatly.
However I think that v.5 will be very different from v.4

these confirmed, but I have read some discussion, and this should not be too difficult to update.
Ideally, it is necessary to work by module, thus during a critical update, only the modules updated need to be modified.
Rarely the integral logic of your application.

 

[Exca]

Currently I would go with pixi v4. It is pretty mature library at current point.

Depending on your project the same code will work on v3, v4 and v5 with small modifications. Though if you do something like custom renderers, filters, meshes and so on then you most likely need to do a lot more migration work if you want to change the major version.

Inside a major version I have had no troubles updating.

I have about 5 projects still working nice with pixi v3 and have had no problems from clients and havent done any updates related to graphics to those after they have been released (2-4 years ago). Same story with pixi v4 projects, the graphics part rarely needs updates.

[b10b]

Risk is minimal.  Minor updates are usually for specific reasons - a particular feature or bug fix.  So there is often only need to update if such feature or fix directly affects our project, sub-library, or user base.  Generally this is rare for a library as mature and well tested as Pixi.

Major versions (and resulting deprecation) can be very exciting for early adopters but should be considered a "new book" - before opening we should check if we've finished the previous book and pre-identify why the new book is better.

[botmaster]

Risk is big in my experience, I built an entire framework around PIXI 4.1.something and when later tried to update to PIXI 4.5.something (I think it was 5) all hell broke loose. This was a huge disappointment to me, I was expecting PIXI 5 to do that eventually but not while still in version 4. I did evaluate the changes and found they were deep and numerous to the point that my framework would have to be completely rewritten. problem is I already have a bunch of apps in production and I can't throw so much testing time down the toilet and start over. So I'll stick to 4.1 for now and make the updates myself and as for PIXI 5 I might have later to adapt it to my framework and not the other way around. It's really a trend that I think Apple started with all frameworks nowadays, why being backward compatible when you can simply just not care about it at all. 

[Jacky Tea]

On 6/14/2018 at 5:19 PM, botmaster said:

Risk is big in my experience, I built an entire framework around PIXI 4.1.something and when later tried to update to PIXI 4.5.something (I think it was 5) all hell broke loose. 

Just curious about this - would you mind giving an example of what happened?

[botmaster]

The event system among other things, it's completely different in 4.8.+ than 4.1.0. This is the kind of change that usually require a 4 to change to 5 .... It completely skips the npm package system that is built on that idea that all major change must increment the major version value. I made it works ultimately by doing some very deep fix in my code base and cross my fingers ....

[xerver]

Quote

It completely skips the npm package system that is built on that idea that all major change must increment the major version value.

We do follow semver to the best of our ability. I went back through the release notes and didn't see any major overhauls to the event system. We still use EE3, and anything we deprecate or break compat with should move into the deprecated.js file and continue to work (with warnings).

That being said, we are human and it is possible for us to break things from time to time; either intentionally or not. But, we've done a pretty good job not doing this and it has been very rare that any breakage has occurred. We definitely don't ignore semver, and the guarantees it gives users.