Pixi.js: Creating branches 4.5.x, 4.6.x, 4.7.x for bugfixing and releasing corresponding versions

[flashist]

Hi

As a continuation of my question: https://github.com/pixijs/pixi.js/issues/6971

I was wondering if it's possible to create 4.5.x, 4.6.x, 4.7.x branches for fixing buges in them and publishing corresponding versions?

It's needed in our projects, because we have 150+ games with different pixi.js versions and we need one specific bugfix for the iOS 14 which exists only in verrsions >= 4.8.8 , but, unfortunately, we can't just update our games to the 4.8.8 version, because it causes errors =(

Thanks in advance.

[bigtimebuddy]

I create legacy release branches when it's appropriate, easy and someone asks, like you did. I'm not going to create a bunch of unnecessary branches. It takes time like it did for 4.4.x, and time is my most finite resource.

Also, you've been kind of vague about it, but knowing what breaks when you update is useful information. I'm sure others have experienced your issue.

[flashist]

@bigtimebuddy , we have 150+ games and trying to find the most appropriate way to update them all to get the needed bugfix from the 4.8.8 version: https://github.com/pixijs/pixi.js/pull/5740/commits/2d50b0526d7aee8075ec3e60eac254172ea0ca26

To be honest, I didn't expect rejection in this questions, because it worked great with the 4.4.x branch and cherry-picking the needed fix from the newer versions to the older ones:
https://github.com/pixijs/pixi.js/issues/6971
https://github.com/pixijs/pixi.js/pull/6972

In a nutshell, all we need is to get 4.5.x, 4.6.x and 4.7.x versions to cherry-pick the bugfix there. And my plan was to prepare all the needed pull-requests to these 4.5.x, 4.6.x, 4.7.x versions and get published and fixed versions (it looks like it worked good in case of the 4.4.x branch).

In case of the 4.4.5 version it worked great for us and the 4.4.x based games work good (at least those, which have been tested by QA so far).

About the specific breaking changes: there are a lot of them and to be honest we don't know which ones exactly cause problems. But as we discussed in another thread, pixi.js doesn't follow semver (though maintainers try to), which means that update from 4.4.x to 4.8.8 might cause problems and errors.

[flashist]

Sorry if I didn't provide enough details about "why we need 4.5.x, 4.6.x, 4.7.x branches":

1. We have 150+ games which need the specific bugfix.
2. All games depend on 4.4.x, 4.5.x, 4.6.x, 4.7.x and 4.8.x versions of the pixi.js module.
3. We tested couple of games from each group and updating to the 4.8.8 version causes problems (there are different errors, e.t.c)
4. So we decided to try to publish separate 4.x versions of pixi.js for each group of game, to make sure we minimize differences between old pixi.js versions and new ones.
5. This approach worked great for 4.4.x games so far, so we would love to use the same approach for other games.

[bigtimebuddy]

After working on your v4.4.x release, I realized that I way underestimated how much effort goes into making legacy releases--even for something like a trivial cherry-pick. There's legitimate maintenance costs in supporting those old versions and I would say that's currently not inline with the goals or resources of the project. While you probably spent a few minutes making that PR, I spent a few hours fiddling with Travis, making sure everything published correctly and got uploaded to the CDN, and release notes were made. Because earlier v4 releases rely on much older tools, and deploying, it was not straightforward.

That leaves us a few options:

• Your company maintain their own fork releases and pay the maintenance cost yourselves. Alternatively, you could also hack in monkey patches for critical fixes.
• Your company becomes an active sponsor of the project which would enable us to find someone to manage these legacy releases more effectively.
• Upgrade all your games to v4.8.x and we solve the underlying breakages.

We could also do a combo of all three.

[flashist]

@bigtimebuddy , I can make all the publishing work, if it's needed. It would be great if there is smth similar to the release 4.4.5 you made, so I can check how builds are configured and release notes are written.

P.S.: it's my vacation so I'm doing it in my free time, to be sure, that when I'm back to work all versions are prepared.
P.P.S.: in my opinion, what you've said, is far far from the "holy open-source spirit" where we can fix everything we need, if it's needed, under the strict guidance of maintainers (ppl with more experience, than me).

What you've said is basically "PAY", which, to be honest, is not what I thought would be a good sign of an open source software (especially, taking the fact that I would love to contribute to the pixi.js lib).

[SukantPal]

@flashist Keep your language in check here, buddy. Those edits don't hide what you've originally wrote.

Whether you like it or not, this won't happen without _you_ doing it. We're happy to accept _your_ contributions; just don't expect us to do work that specifically pertains only to you.

[GoodBoyDigital]

Hey there @flashist

I think the ‘pay to fix’ is perhaps a little misconstrued. With the use of the word ‘cost’ @bigtimebuddy is not referring to money, but time. We basically have a finite amount of time we can all spend on the project due to all of life’s other commitments.. kids, work.. you know how it goes!

With that time we are currently prioritising pushing Pixi forward :D

Great to hear that you are happy to help out maintaining older versions though. With all those games, certainly feels like you and your team are best placed to identify and handle any problems with older versions. Im sure there will be some other devs out there that would benefit from this work!

Above all, lets try too keep our conversations respectful, we all want the same thing at the end of the day :)

[flashist]

Yeah, sorry for me being too emotional (though I already edited the texts, because I calmed down and realized that politeness is the best tactics, being rude - not).

May I ask somebody to guide me through the procedures of creating and maintaining old branches?

As I said, I would love to do that with the guidance (reviewing) from other ppl.

As far as I understand I can't create 4.5.x, 4.6.x, 4.7.x branches by myself, because I don't have permissions for that. Should somebody create them (as I asked in the initial description of this thread) or should somebody give me a permission to create these branches?

P.S.: I'm familiar with branching models, tags, etc. (though at work we use Bitbucket for these purposes), so I feel pretty confident in fulfilling the task by my own.

[themoonrat]

I'll add that I am also in the position of running a dev team that makes and maintain lots of slots games, close to around 100 now that use PixiJS, and we went down the down the 'maintain my own repo for PixiJS' route.

Sometimes we are in-sync with the official repo. Sometimes we've pulled in PRs / patches ahead of official approval. Sometimes we've got fixes locally, and then I open up and submit a PR to the official repo. Sometimes we've had permanent differences to the official repo. A lot of my contributions to features in PixiJS v5 were improvements I'd built up in our own version of v4, and the major PixiJS version bump was a good time to see which ones were publicly useful! So now the diff between official v5 and our v5 is quite small, whereas official v4 and our v4 got fairly large!

We do this with a number of client side libraries, like this, like Howler, as this way my team can be 'masters of our own destiny'. There's never a blocker on waiting for a third party to write a fix, or approved a fix, or release a version with a fix.

This may not work for your team, but just some thoughts from someone in a similar position, in case it helps you or perhaps others who are wondering how others have gone about solving this dilemma.

[flashist]

@themoonrat , thanks a lot for the idea! It makes perfect sense, but, in the near future it probably won't be possible for us to switch all those games to our "in-house" version of the pixi.js (especially knowing that all imports should be changed and all games should be rebuilt.

So I would love to be able to maintain old branches if the pixi.js community would allow me to.

[flashist]

@GoodBoyDigital, @bigtimebuddy may I ask to update me with the information about maintaining 4.5.x, 4.6.x, 4.7.x branches?

Should I wait for the permission to create them?
Should I wait for smb else to create them?
Should I stop asking a lot of questions here because the pixi.js team decides that it's not important and we should find another way of bug fixing in old games?

Thanks in advance!

[bigtimebuddy]

I'm traveling through next week and @flashist we can chat more about this when I'm back since the release management stuff is more my domain. If you're looking for an answer right now, the route @themoonrat suggested is by far best option and would _highly_ encourage you to try that first.

This project is based on trust with its volunteers and the community. We have asked people to join the team because they have contributed, participated in constructive discussions, reviewed PRs, closed issues, and behaved professionally. Basically, they've all earned that trust. We've also asked members to leave because they've broken that trust and treated the community with disrespect or behaved unprofessionally. I accept your apology for being rude and while I appreciate the offer to help with some of the publishing lift, you've behaved in ways that we'd be disinclined to give you write access to the project or publishing rights. If you want to earn back trust, please continue to help the project by contributing outside of your immediate needs, and then we can discuss getting your assistance with publishing.

Since it was straightforward, I have gone ahead and created v4.[5,6,7].x branches from the latest tags on those minor releases. Hopefully this can be helpful as a starting point for you creating your fork to address the legacy issues in your games.

[flashist]

@bigtimebuddy , thanks for creating branches. PRs with needed fixes are created (I'm not hurrying you, just mention that fixing from my side is done).

[flashist]

@bigtimebuddy , please, could you share some ball park figures for the date of reviewing / releasing the mentioned branches (so we are able to plan our work according to this information) ?

P.S.: again, no hurrying, just to be on the same page with the pixi.js team