search

gbdev / rgbds

Rednex Game Boy Development System - An assembly toolchain for the Nintendo Game Boy and Game Boy Color
https://rgbds.gbdev.io
MIT License
1.33k stars 175 forks source link

Fix tests with depracated syntax #991

Closed DaKnig closed 2 years ago

DaKnig commented 2 years ago

when running the automatic tests, they pull and compile ucity from github, which has an old codebase using syntax that is now considered to be "obsolete". I would suggest that irrelevant warnings be filtered out by scripts in order for the real warnings to be more visible- I mean, it gives so many warnings that I cant scroll over them to see if all the main tests pass...

aaaaaa123456789 commented 2 years ago

Is ucity still maintained? Would PR'ing it to use modern syntax be a plausible alternative?

DaKnig commented 2 years ago

I believe RGBDS, being a legacy project, should correctly behave and process old codebases- and while warning the user is important, it would be a good idea imo to test if it actually behaves correctly on old codebases. maybe ucity is the best testcase for this?

Rangi42 commented 2 years ago

I see a lot of `SET` for variables is deprecated; use `=` warnings. These are something that should be corrected in ucity itself, since deprecated syntax will eventually be removed, typically in the next minor version (0.6.0). In general old codebases are expected to use older version of rgbds.

AntonioND commented 2 years ago

uCity is now fixed: https://github.com/AntonioND/ucity/commit/199ef267efd80b7949699895b39f36622da5bc7d

And also other warnings: https://github.com/AntonioND/ucity/commit/4530b06658c1fad7e64f023966616a42049fb3cc

AntonioND commented 2 years ago

If you want to update the commit used for the tests, you should use https://github.com/AntonioND/ucity/commit/d8878233da7a6569f09f87b144cb5bf140146a0f

ISSOtm commented 2 years ago

Handling backwards compat is currently not on our list, as it would take up too much time, which is already lacking in updates. We instead compromise by keeping the breakage reasonable, keeping old versions up and documented, as well as going through slow and smooth deprecation processes.

It's possible later versions may get compatibility toggles (once we get a custom parser, at least), but the 0.x series is currently not aimed at strict backwards compat.

The only thing we expect in return is that long-term users either stay on the "bleeding edge", or document the version they are using. (That's often not the case, but you can infer the version from the date most of the time, and being off by one or two versions is typically fine.

Projects in our CI are implicitly expected to be the former kind due to the nature of CI; it is appreciated if the changes make it upstream, for obvious reasons, but forking is also a possibility, for example if contact has been lost.

With that said, thank you @AntonioND for making the suggested changes! And thus, closing this issue. The above should be considered as "for the record" of our stance on backwards compat, at least for the 0.x series. We will start honoring SemVer properly once we finally reach 1.0.0.