I really disagree with this.
Sure, it's always better for new people to learn the new version and update it themselves....
So actually you don't disagree.
but what if people don't have programming skills and just want to compile a homebrew? I don't see any problem with that.
This assumes that building homebrew without programming skills is a reasonable expectation in the first place. There are many reasons why it isn't but in the end the best solution is to seek out someone willing and able to help. Sometimes though you might have to accept that some homebrew will never compile in it's current form.
Take Puffle Paddle 3DS for example. The latest devkit can't compile it and I can't find a build anywhere. I also know it works because I remember before wiping my SD card playing it just fine.
So now how am I supposed to play it?
It took me barely 2 minutes to find a binary, unfortunately that binary doesn't seem playable.
Updating for latest tools was around 10 minutes or so & most of that was puzzling over why it appeared to be randomly exiting. Looks like the original author was testing the intro screen & didn't want to press start to exit ¯\_(ツ)_/¯
The changes are minor at best -
https://github.com/gatuno/PaddlePuffle3DS/compare/master...WinterMute:master although the project could really do with being refactored to take advantage of tool & library improvements we've made since it was started.
Yo can find a current binary at
https://github.com/WinterMute/PaddlePuffle3DS/releases/tag/v0.1.1 (and this wouldn't really be necessary if people used github releases instead of uploading things to random places)
That's working great for
Gecko OS, right? "If we can" you say? What about when you can't do it or don't want to do it? What then? If only there was a way to get the old, original tools for quick, one-off changes to old, abandoned projects...
The Gecko OS fork found in that thread compiles fine with latest tools but the user who wanted help made life difficult by manually applying changes he was told would be PR'd once some further fixes were made. Presumably he's lost interest now & there's not really a lot we can do without further feedback.
The other aspect of this is that if we don't know something is broken then we can't fix it. If the first thing people do when faced with a compile error is to go hunting for old versions because "it's a quick, one-off change" then bitrot happens and people get trapped.
If you want to never update & stick with the tools currently on your hard drive then that's up to you. Forcing other people to use the same outdated tools as you is inappropriate, painful and unnecessarily cruel - even more so if it's some kind of hybrid of component versions that weren't released or tested together.
Obvious answers, sink months into building a new toolchain from scratch, "obtain" an older version of a devkitPro toolchain, or sink numerous hours fixing their backwards incompatibility issues. All three ways are a vastly superior user experience than providing one off binaries until if/when the updated toolchains can be fixed to correct backwards compatibility problems.</sarcasm>
There's a wealth of assumption here, not least that the updated tools and libraries are somehow responsible for a project that won't build. As I've said in numerous other places by far the most common problems are relatively minor API changes and improved toolchain diagnostics combined with people ignoring compiler warnings. Sometimes people have used library internals that were in a state of flux despite being advised not to. Calling these things "backwards incompatibility issues" is, for the most part, a rather serious misrepresentation.
So everyone that forks it by your definition is somehow violating your trademark too?
Yes, that's how trademarks work. If you modify our work and release it independently then you're potentially tarnishing our reputation as well as trading off the brand recognition we've achieved over the years. A *lot* of work has gone into putting together a set of tools and libraries that make it much easier to create homebrew. There's still a lot more work to do and it would be a lot easier if we didn't have to deal with the fallout and abuse that results from people inappropriately redistributing our work rather than fix a broken project.
Yep. Absolutely absurd to have a working solution without needing to work around YOUR backwards compatibility problems.
Again, most issues are with the projects that insist on doing things in inappropriate ways despite being advised not to. I have literally been told that fixing warnings is too much work despite the fact that the warnings reveal the root cause of the crash bug that allegedly got introduced by the toolchain release after the release that builds a working binary.
It is *not* our responsibility to hunt out every project using our tools and ensure that they all build and function with every new release. Ultimately we have a collective responsibility to learn and support each other or it all descends into unmaintainable chaos.
I realise many of you have no recollection of just how difficult it used to be to even think about collaborating but it would be really good if you stopped trying to drag everyone backwards because you don't want to ask for help or you want to ignore the advice you're given because it means spending a few days fixing up a source tree.
Hanging on to outdated and buggy tools traps you and everyone else you come into contact with. Please stop doing it.
