this post was submitted on 19 Mar 2024
170 points (96.7% liked)

Firefox

17952 readers
445 users here now

A place to discuss the news and latest developments on the open-source browser Firefox

founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] cupcakezealot@lemmy.blahaj.zone 8 points 8 months ago (3 children)

just out of curiosity why did browsers move to the rapid releases of the >120 version numbers instead of the lower numbers?

[–] ahal@lemmy.ca 8 points 8 months ago (1 children)

In the rapid release model there are no updates bigger than the regularly scheduled releases. So each regularly scheduled release needs to bump the biggest version number. Otherwise the biggest number would never change and there would also be fewer ways to distinguish smaller releases.

[–] sugar_in_your_tea@sh.itjust.works 5 points 8 months ago (1 children)

That's not necessarily true, they could totally use semantic versioning (but without the requirement for a breaking change) and bump the major version when there's a big user-facing change. For example, Firefox Quantum would've been a great time for a version bump. Or they could do with Year.Release versioning like Ubuntu does.

I think either of those are more useful than the current sequential numbers because they provide some additional information. I like the Major.Minor style so I have an idea of how significant the changes are.

[–] ahal@lemmy.ca 3 points 8 months ago (2 children)

True, but one problem would be that every release would break something as there are just so many changes in each. On this scale SemVer doesn't work that well. It also doesn't really tell you anything about the significance of changes (trivial changes can cause major bumps, or huge new features can be fully backwards compatible).

Dates could work. Though Firefox 2024.03 just doesn't have the same ring to it :p. And they also don't say anything about significance.

[–] sugar_in_your_tea@sh.itjust.works 3 points 8 months ago (1 children)

Yes, you'd have to change the definition of a major release from "breaking change" to "big change." Your normal releases would increment the minor version, security fixes would increment the patch version, and big changes would increment the major. Whether something is "big" is pretty subjective, but they provide an opportunity for marketing.

Or if we want to go with something objective and simple, the major release would correspond to an ESR release, which happens about once/year.

The purpose here is to make the numbers mean something rather than "number goes up." If you ask me what was in Firefox 120, I would have no idea because large numbers are harder to remember than smaller numbers.

[–] ahal@lemmy.ca 1 points 8 months ago

Yeah it could work too. Like you said though it's subjective and internal arguments about what deserves to be big or not sounds tiring :p. For marketing large changes, inventing a buzzword seems to be working well enough.

I guess to each their own, but I kind of like not knowing the version. I just use Firefox and if I really care what's new I can look at the changelog, or see it in the what's new pop-up.

[–] Gallardo994@sh.itjust.works 1 points 8 months ago (1 children)

I would sincerely advocate for year.month or year.release model so that typical users can figure out how outdated their software is. An average person is usually terrible at keeping software up to date.

[–] ahal@lemmy.ca 2 points 8 months ago

At least for Firefox the average person is getting updated automatically. They'd need to go into about:config to turn it off.

[–] Midnitte@beehaw.org 7 points 8 months ago

Seems like they'd be better off using something like year.month to give better context

[–] Rudee@lemmy.ml 5 points 8 months ago

Bigger number better

...probably