Page MenuHomeSolus

Update LOVE to 11.2
AbandonedPublic

Authored by hafermix on Jan 9 2019, 9:06 PM.

Details

Reviewers
DataDrake
Group Reviewers
Triage Team
Summary

Release notes available here

Test Plan

Test a project which worked previously in LÖVE 11.1

Diff Detail

Repository
R1979 love
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
hafermix created this revision.Jan 9 2019, 9:06 PM
hafermix requested review of this revision.Jan 9 2019, 9:06 PM
DataDrake requested changes to this revision.Jan 16 2019, 12:39 PM
DataDrake added a subscriber: DataDrake.

Has this been tested with sienna, duckmarines, and mrrescue?

This revision now requires changes to proceed.Jan 16 2019, 12:39 PM
hafermix added a comment.EditedJan 18 2019, 2:31 AM

Of these packages only mrrescue worked, since it's the only game which was updated to LÖVE 11. The other two packages still use LÖVE 0.10, even after the library was updated to 11.1, so they've been broken since May 4, 2018. There's a PR for duckmarines to support LÖVE 11, but the author didn't look into it yet. I think the broken packages can be removed.

Of these packages only mrrescue worked, since it's the only game which was updated to LÖVE 11. The other two packages still use LÖVE 0.10, even after the library was updated to 11.1, so they've been broken since May 4, 2018. There's a PR for duckmarines to support LÖVE 11, but the author didn't look into it yet. I think the broken packages can be removed.

No. Why would you even suggest that? -_-

We should probably bundle any games that don't work with their own version of Love, otherwise we'll be stuck in a holding pattern and never able to update Love.

We should probably bundle any games that don't work with their own version of Love, otherwise we'll be stuck in a holding pattern and never able to update Love.

With respect, the only reason Love is in the repo in the first place is to support those games. If it is held back to support them that's fine. We don't ship Love for the purpose of supporting other things.

With respect, the only reason Love is in the repo in the first place is to support those games. If it is held back to support them that's fine. We don't ship Love for the purpose of supporting other things.

That's too bad, I would hope Love would be bundled for the sake of developers using Love, if it only exists to support games that require it, that's a tricky endeavor. They have a history of breaking the API. If you want to support multiple games, you end up with a scenario like we had over at slackbuilds.org, where you are maintaining several legacy versions of Love. Maintaining the required version with the game makes it more modular, and won't keep anyone from not being able to develop with Love on Solus.

Well as the one who put it in in the first place, I'm just telling you why it exists. If people want to use it for development that's a slippery slope. I don't want to have 10 different versions because updating it breaks someone's current projects either.

Well as the one who put it in in the first place, I'm just telling you why it exists. If people want to use it for development that's a slippery slope. I don't want to have 10 different versions because updating it breaks someone's current projects either.

Which is why bundling it with the game makes more sense, because otherwise you end up in that 10-version-state. As it is now you have neither the up-to-date version or a version that works across other packages (worst of both worlds).

Not really. We have a version that works for what we ship. If we offered an up-to-date version, people would just complain every time we updated it that it broke their projects. Right now there aren't any new packages waiting on this update.

Not really. We have a version that works for what we ship. If we offered an up-to-date version, people would just complain every time we updated it that it broke their projects. Right now there aren't any new packages waiting on this update.

That's not true, the only package that currently works is mrrescue, of the three mentioned.

That's not true, the only package that currently works is mrrescue, of the three mentioned.

Well this is news to me and will need to be looked into. But that still doesn't change my stance.

That's not true, the only package that currently works is mrrescue, of the three mentioned.

Well this is news to me and will need to be looked into. But that still doesn't change my stance.

It was reported earlier in this thread:

Of these packages only mrrescue worked, since it's the only game which was updated to LÖVE 11. The other two packages still use LÖVE 0.10, even after the library was updated to 11.1, so they've been broken since May 4, 2018. There's a PR for duckmarines to support LÖVE 11, but the author didn't look into it yet. I think the broken packages can be removed.

Congratulations. You're right. When I read that I was under the impression that he was referring to testing with this patch. That still doesn't change my stance.

Congratulations. You're right. When I read that I was under the impression that he was referring to testing with this patch. That still doesn't change my stance.

Well, these packages must not be very popular if no one noticed since May 2018 ... perhaps dropping them and only maintaining Love would be better, running a game with Love is quite simple. Just my thoughts, for me, I really want the latest Love on my machine for development, and the Reddit thread I started on Solus' Reddit seemed to confirm that other users felt the same way. Maybe you could offer a love-dev package that was more constantly updated, and then have a stable version for the sake of games that depend on Love, which there seem to be very few of currently.

JoshStrobl added a subscriber: JoshStrobl.EditedMay 14 2019, 11:26 PM

It is standard policy for us to not supply multiple providers of a library and we only allow it in extreme cases. You don't see us packaging multiple versions of nodejs (I keep it at LTS because of the applications which require it, even as a nodejs dev) or development tooling like MariaDB, PHP, etc. As @DataDrake stated, LOVE was never added for the purposes of development, but rather because it is a build dependency of other applications. This was the case for nodejs (I packaged and landed it for Atom). This was the case for mono (I remember, because I was there when it first landed in the EvolveOS days, so I could compile Keepass). This was even the case for Lua and because of the shear amount of applications (not developers) which require Lua 5.1, as well as the ease in which we can maintain both versions that have significant ABI differences, the exception was made in that specific case. I would know, because I was the one that made that original decision and packaged lua51 in the first place.

@DataDrake's decision on the matter is final. Should all of the items in our repository that build with LOVE introduce support for newer LOVE in stable releases, we will bring this up to the latest release. We, as a project, have no qualms with holding back packages. It's what makes us a curated rolling release. We perform package / stack upgrades when it makes sense, this is not one of those cases. It is entirely normal for us to be on the bleeding edge for certain package sets, and be more conservative on others.

Thank you for your thoughts on the matter. @DataDrake can decide what to do from here when it comes to the patch.

DataDrake abandoned this revision.May 14 2019, 11:35 PM
ryanpcmcquen added a comment.EditedMay 14 2019, 11:37 PM

It is standard policy for us to not supply multiple providers of a library and we only allow it in extreme cases. You don't see us packaging multiple versions of nodejs (I keep it at LTS because of the applications which require it, even as a nodejs dev) or development tooling like MariaDB, PHP, etc. As @DataDrake stated, LOVE was never added for the purposes of development, but rather because it is a build dependency of other applications. This was the case for nodejs (I packaged and landed it for Atom). This was the case for mono (I remember, because I was there when it first landed in the EvolveOS days, so I could compile Keepass). This was even the case for Lua and because of the shear amount of applications (not developers) which require Lua 5.1, as well as the ease in which we can maintain both versions that have significant ABI differences, the exception was made in that specific case. I would know, because I was the one that made that original decision and packaged lua51 in the first place.

@DataDrake's decision on the matter is final. Should all of the items in our repository that build with LOVE introduce support for newer LOVE in stable releases, we will bring this up to the latest release. We, as a project, have no qualms with holding back packages. It's what makes us a curated rolling release. We perform package / stack upgrades when it makes sense, this is not one of those cases. It is entirely normal for us to be on the bleeding edge for certain package sets, and be more conservative on others.

Thank you for your thoughts on the matter. @DataDrake can decide what to do from here when it comes to the patch.

If that is the case, then Ikey's update from May 2018 should also be reverted, so that the games that are packaged for Solus and depend on Love can function again.

If that is the case, then Ikey's update from May 2018 should also be reverted, so that the games that are packaged for Solus and depend on Love can function again.

Already done in Unstable. As well as reverting mrrescue.

If that is the case, then Ikey's update from May 2018 should also be reverted, so that the games that are packaged for Solus and depend on Love can function again.

Already done in Unstable. As well as reverting mrrescue.

Cool.