141–150 of 195 posts
Oh no, not this. Every new release means hours spent on rebasing patches, investigating why the new version won't compile and then create more patches. When Firefox finally builds, I now have to find out what they have removed/changed that worked fine before, and what new crap that should be disabled in about:conf. I need LESS of this, not more..
Earlier quoted context omitted.
Cmd + alt + r
I don't know what cmd means (I'm kidding, I have seen Apple computers even if I've never used one), but you can find out what the keyboard shortcut is on your own copy of Firefox by hovering the mouse over the Reader mode icon. On my Firefox it says "Ctrl + Alt + R".
Firefox 38 for reader 50 for a hotkey.
Earlier quoted context omitted.
Notice that almost all the positives of quick release cycles are about how they make it easier for developers? I think is telling of where tech culture is these days. IME frequent updates terrify non-technical users, any given update might change the UI, remove a feature the use or add some other complication (like simply not working) at an inopportune moment. Big fat updates give them a chance to prepare for these c…
That’s what I am thinking. I hate it when my browser or a phone app suddenly looks different without warning.
Oh no, not this. Every new release means hours spent on rebasing patches, investigating why the new version won't compile and then create more patches. When Firefox finally builds, I now have to find out what they have removed/changed that worked fine before, and what new crap that should be disabled in about:conf. I need LESS of this, not more..
You're not obliged to update every four weeks. Why not continue updating as often as you currently do?
Earlier quoted context omitted.
You're not obliged to update every four weeks. Why not continue updating as often as you currently do?
There will usually be many security fixes with each new release, so I have no choice.
Wrong decision. Nobody wants to update their browser this frequently, and the release overhead is a constant factor. So you're basically having a lot less productive time where you actually produce value. But hey, not my call I guess.
I've always wondered this: why release on a schedule at all? If people demand a certain new feature ("[this will] bring you new features more quickly"), it can just be brought out as it's ready, instead of having to wait an average of 3 (now 2) weeks before it can be released? And why does this have to increment the major version, since when is every single update backwards incompatible?
https://herbsutter.com/2019/07/13/draft-faq-why-does-the-c-s...
Earlier quoted context omitted.
I think it's more a matter of discipline than anything else. It's easy to get lost in the weeds with a ton of things waiting to be merged, and over and over saying "just one more PR to merge and then I'll release", and then it's a year later and you still haven't released. Getting features out to people faster means shorter feedback cycles. Regarding versioning, most applications don't use semantic versioning; that's…
Addons, plug-ins, CSS and HTML directives, etc.
Earlier quoted context omitted.
Quality can be worse in a long-time cycle project: - Engineers are motivated to slam their feature in, because if they miss the train the next one's not for 12 months. - You get one moment per year to connect with your customers & understand how well/not well your changes worked. This means either riskier things happen or that innovation slows to a crawl. My 2 cents, speaking from some experience working on long time…
I've been in both situations of missing the 12 month boat, and rushing to get something in before the boat leaves port, and it's terrible. that said I think 4 weeks is a real short release cycle. 3 months, so 4 releases a year -- one for each season. Would seem to strike a better balance.