Hi Richard,<br /><br />Thanks for the explanation. I fully understand the reasoning behind your decision, but I really think this issue requires specific treatment due to its nature.<br /><br />Ideally, customers using our legacy products (and thus, really old versions of our Yocto distribution) would migrate to newer products running newer software, and these situations would be avoided altogether. However, we're talking about products that are already in production, with several devices in the field that require periodic updates. Maintaining outdated software, while not recommendable from several standpoints, is oftentimes a more efficient approach than migrating to something newer, especially in these cases.<br /><br />Older Yocto builds are still possible for us and our customers via docker containers or virtual machines, which provide "old" environments where the builds still work, despite all of the missing fixes in bitbake/poky. Basically, rather than patching the Yocto stack to fit our environment, we adapt our environment to fit the Yocto stack - again, because several legacy customers have made the decision to depend on old Yocto versions.<br /><br />Having said this, I believe GitHub's deprecation of the <em>git </em>protocol is a special case because, regardless of the environment you're using or how many patches you've backported so far, builds will simply stop working altogether after the plug is pulled. No matter which environment we use, this is an external factor that's going to force changes in the Yocto stack, in areas that we have little to no control over. We're going to have to fix it either way, but it would be a much smoother transition if the fix were included by the community, and it's a unique enough case to warrant it being patched in older bitbake versions (in my opinion).<br /><br />Forgive me for the insistence, but I truly believe this situation requires exceptional treatment.<br /><br />Best regards,<br />Gabriel