The problem is content exclusivity. It would be great if all the content or at least most would be available on all platforms. At least eventually. That would be great for consumers. Mergers like this typically not.
We could do that by limiting copyright to just 10-14 years. All platforms could have all that content forever without paying a dime. New stuff and exclusives would still be a draw to attract people to one platform or another.
Nah, there's no reason why trillion dollar companies should be allowed to pay anything to keep our shared culture locked up. Doing so only hinders innovation and the creation of new works. 14 years was long enough back when global distribution was unimaginable and any distribution at all was highly expensive.
Today you can instantly distribute media to the entire planet at near zero expense. If you can't make money after a decade you have only yourself or your product to blame. Also, it's not as if once something goes into the public domain all income stops either. With even a small amount of effort creators can continue to successfully package and sell their stuff to the fans even when it's avilable for free. It's worked on me several times in fact.
Another reason I can think of is the requirement not to introduce a breaking change. It is very frustrating if the codebase has a lot of hacky/bad code in it but a lot of it can't be changed...
Because updates don't just include new features but also bug and security fixes. As always, it probably depends on the context how relevant this is to you. I agree that cooldown is a good idea though.
> Because updates don't just include new features but also bug and security fixes.
This practice needs to change, although it will be almost impossible to get a whole ecosystem to adopt. You shouldn’t have to take new features (and associated new problems) just to get bug fixes and security updates. They should be offered in parallel. We need to get comfortable again with parallel maintenance branches for each major feature branch, and comfortable with backporting fixes to older releases.
I maintain both commercial and open source libs. This is a non starter in both cases. It would easily double if not triple the workload.
For open source, well these are volunteer projects on my own time, you are always welcome to fork a given version and backport any fixes that land on main/master.
For commercial libs, our users are not willing to pay extra for this service, so we don't provide it. They would rather stay on an old version and update the entire code base at given intervals. Even when we do release patch versions, there is surprisingly little uptake.
Semver doesn't help. The primary issue is effort. If it's an open source project with 1-2 devs, they probably won't be able to handle supporting multiple branches unless they're being paid to do this.
Of course it doesn't provide backports by itself, it's a versioning system. But version number changes with SemVer are meant to indicate whether an update includes new fearhews or not (minor bump means new features, patch bump means bugfixes only).
Of course, the actual issue is that maintaining backports isn't free, so expecting it from random single-person projects is a little unrealistic. Bug fixes in new code often need to be rewritten to work on old code. I do maintain old release branches for some projects and backporting single patches can cause whole new bugs that were never present in the main branch quite easily.
IMO for “boring software” you usually want to be on the oldest supported main/minor version, keeping an eye on the newest point version. That will have all the security patches. But you don't need to take every bug fix blindly.
I think the problem is that they cannot communicate that they don't know something and instead make up some BS that sounds somewhat reasonable. Probably due to how they are built. I notice this regularly when asking questions about new web platform features and there is not enough information in the training data.
A couple of years ago I played PUBG which crashed occasionally. I rarely submitted bugs, even if it was as simple as pressing a button in the crash reporter. This is because sending the bug report took a while and blocked you from restarting and rejoining the ongoing game. This applies mostly to multiplayer games but if your app has a crash reporter, give the user a chance to restart the app and report the bug later.
The opposite would be something like the bug reporting system in Second Life by Linden Labs (an online world where you can be with a virtual avatar, doing stuff) (at least way back, i dunno if they still have that open).
They had a public facing jira open, where people could file bugs and what not about the viewer (the client) and the world (the server).
You didn't need some special account or something like that, just your normal Second Life account was enough to get access to that one.
Drawback was, you were able to see what happens when filing bugs is easy. Of course, many people used it to file real bugs but also complained about stuff not working like they expected (or how it should work according to them, which brought other people up against them and so on...in the end you were able to read the latest drama here and there, right in the jira entries).
Although, to be honest, i thought it was an awesome idea, but you when you open up an easy way for people to report bugs, you need an easy way to explain what bugs are and what not. :)
reply