181–190 of 195 posts
I think this is sad news, but that's because I view the current "rapid release" trend and being, on the whole, a bad thing for everyone. It decreases software quality, decreases stability, and increases hassle and stress for everyone from developers to users.
Earlier quoted context omitted.
Good point, but factor in build/release, then deployment. We all know what some companies are like in their desktop real estate rollouts - if you have too frequent updates, you end up with greater disparity in releases with a template support of - oh that's not the latest, pls try again. Then feedback, if you rollout release too frequently you also can be several releases in and get feedback of some bug in a release…
> kudos for not just picking a day a month and doing monthly updates like most, that tends to seem more arbitrary unlike 4 weeks Planning feature development and rollout is more difficult if you always have to refer to a calendar to find future release dates. I would prefer to be able to say a feature can land in Firefox Nightly in January, ship to Firefox Beta on February 1, and Release channel users on March 1. Moz…
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?
At my work the culture is just to ship changes as soon as they improve the product/codebase
Earlier quoted context omitted.
Right. Desktop software is also much more difficult to QA than server software because of the lack of control over the environment and the difficulty of rollback.
Also, for desktop software, I have found that small releases are a lot less risky. You experience small issues, one by one, instead of a massive amount of bugs coming all of a sudden. For example, last time I updated a Linux distribution with 6-month releases this was the case. Whereas with a rolling release one, it's just much more pleasant.
Earlier quoted context omitted.
Semantic versioning is useful for libraries. Let useful for consumer apps. 2019-10 says more than 76.0.0
Well, I don't get an idea if my extension would break changing from version 2019-10 -> 2019-11 without reading the release notes. I would know it there is a big chance of breakage if I moved from 76.0.0 -> v77.0.0 and I am reasonably certain it won't break if I moved from 76.0.0 -> 76.0.1
Since there are more websites than extensions, the utilitarian approach would be to choose 2019-10 over 76.0.0.
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?
Firefox ships ~100 binaries for 100 different targets, from mobile phones, to desktops, tablets, ... x86, arm, sparc, ppc, riscv, ... X linux, windows, macos, freebds, openbsd, netbsd, .... X arch linux, debian, ubuntu .. At some point you need to say this is what we want to ship, and branch, and make sure that not only all tests pass, but that the installers work, run the benchmark suite that might not be run on eve…
Earlier quoted context omitted.
Mozilla only provides binaries for Linux 32-bit, Linux 64-bit, macOS, win32, and win64: http://ftp.mozilla.org/pub/firefox/releases/69.0/ All of the various Linux distributions just repackage those binaries. iOS and Android are distributed only through the App Store and Google Play. The BSDs and other ("tier 3") platforms have to compile from source and distribute their own packages: https://developer.mozilla.org/en-…
Although this comment was already debunked, I'll add Arch's Firefox PKGBUILD here [1]. And to save you a click, they compile it from a source tarball. [1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/P...
https://git.archlinux.org/svntogit/packages.git/tree/trunk/P...
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.
>Nobody wants to update their browser this frequently Uhh really? Pretty sure "most people" don't even notice when their browser updates.
Earlier quoted context omitted.
Why cycles at all? Why not look at what features have been integrated, whether they make up a set that you want to release, and then release? Neither long cycles nor short cycles make any sense. Some features take a long time to develop, some take a short time to develop. Sometimes features that take a long time to develop aren't user-facing enough to be worth releasing for, and sometimes a quick fix has a huge impac…
Because regular, predictable releases mean that developers know they can always "catch the next train", and users know they can plan around predictable upgrade schedules.
This is an argument for frequent releases, not regular, predictable releases.
> users know they can plan around predictable upgrade schedules.
I'm not sure this is actually how users plan upgrades.
The majority of individuals probably never turn off the auto-update flag. Planning doesn't enter the equation.
For organizations, my guess is that most organizations will try to build their upgrade process around security, but the reality will rarely be so clean. When I worked in IT we'd get computers into our shop that hadn't been updated. Period. We'd upgrade our provisioning images when there was a notable security patch, and besides that, we just would run updates on every machine every week at 2am Sunday night: that way it didn't interfere with users, but if something went wrong, we were on it with the full team first thing Monday morning. But if machines were turned off or whatever, they wouldn't run the updates. At no point did we ever even check the release schedule of a piece of software: the updates happened on our time, and theirs was irrelevant.
I didn't work in IT for very long, though, so someone with more IT experience should correct me if I'm wrong.