Talk:History of Firefox

Proposal to change introductory paragraph

The article's introductory paragraph consists almost entirely of chronological information.  This type of data is best presented as a table, not as prose.  Currently, it feels pedantic and tiresome.  I propose to shorten the paragraph to contain only 1-2 dates, followed by a table that contains the full information.  Any objections?

--Black Walnut (talk). —Preceding undated comment added 18:23, 7 October 2018 (UTC)

Merge version-history tables back to here

Well, the decision to split the version-history tables off into their own article has resulted in a deletion discussion leading (somehow) to that content being dumped ("merged") into the Firefox article (actually, now into a template that is being transcluded into that article [horrors!]). I don't think this was the intent when Rukario-sama moved the information out of this article back in 2017. Therefore, I'm asking Rukario-sama and whomever else is watching this page whether the version-history tables should be merged back into this article, preferably (IMO) in the manner that I discussed at Talk:Firefox version history#Runs afoul of WP:NOTCHANGELOG. (I thought about posting also on this talk page back at that time, but I never got around to it.) In particular, I'm suggesting that we split the info into separate tables in each appropriate (level-3) subsection by version number/range (those shown in the TOC: "Phoenix 0.1 to Firebird 0.7", "Version 1.0", "Version 1.5", … "Version 60–65"), as seen for versions up to 4.0 in this "test" version of the article from 24 September 2018 (diff). Once that is done, we can pare down the information to only major versions, to non-test versions, or whatever, if/as desired. I would just BEBOLD and start doing it, but it will be somewhat time-consuming, so I don't want to start doing it (again) if there will be massive immediate objections. Comments? - dcljr (talk) 10:30, 16 February 2019 (UTC)

Whoops, I guess the version-history tables were actually originally split off from this article by Op47 way back in February 2012. Rukario-sama just "finished the job", as it were. Whatever. [grin] - dcljr (talk) 10:47, 16 February 2019 (UTC)

Another clarification: For those coming from Firefox#Version history, I am only suggesting moving the table portion of that section into this article, not the Firefox#CPU architectures subsection onward. - dcljr (talk) 10:58, 16 February 2019 (UTC) — Statement retracted. I was confused. - dcljr (talk) 22:33, 16 February 2019 (UTC)

Note: Pursuant to the discussion at Talk:Firefox#Firefox version history merge I have deleted the template and restored the article, Firefox version history, pending the outcome of this discussion. bd2412 T 13:59, 16 February 2019 (UTC)

Correction to what I said before: I didn't remember that the content recently at "Firefox#CPU architectures" onwards was actually part of Firefox version history before the recent changes, so, yes, I am suggesting that those sections be part of the merge into this article. Thank you to bd2412 for allowing a possible alternative resolution to this situation. Now, people should actually participate in this merge discussion, since it should not be assumed that the status quo can remain indefinitely. - dcljr (talk) 22:33, 16 February 2019 (UTC)

There's no reason to convert that page into template. If it's to "show up" in another article I'd suggest doing a merger only. Templates have benefit but I don't see one for this. So on the merger thing, I think they looked fine separated. Though if merger was still "necessary" then I want to follow Dcljr's idea you can read more at Talk:Firefox version history#Runs afoul of WP:NOTCHANGELOG. Also hasn't anyone occur that they can be merged the other way around (History of Firefox into Firefox version history)? Seeing that History of Firefox is obsessed with versions, why not, and it'll become like iOS version history. Rukario-sama ^ㅈ^ -(...) 01:29, 18 February 2019 (UTC)

OK, well, since no one has objected to my merge idea, I plan to start implementing that scheme soon. @Rukario-sama: since merging Firefox version history to here is less "disruptive" than doing it the other way 'round, that's what I'm going to do. The whole thing can be moved merged to the other title later by an admin, if "we" decide that's preferable. - dcljr (talk) 04:02, 2 March 2019 (UTC) [Edited to fix misleading statement — the article could not be moved, it would have to be merged to the other title to preserve the edit history, which does not have to be done by an admin. - dcljr (talk) 22:33, 18 April 2019 (UTC)]

I wouldn't say it's disruptive. The history of Firefox will look thin once version history was subtracted from there and then there's Firefox#History that would already got it covered. Rukario-sama ^ㅈ^ -(...) 03:26, 13 March 2019 (UTC)

@Rukario-sama: Are you arguing that "History of Firefox" should or should not be its own article after your suggested merge (of "History of Firefox" into "Firefox version history")? I'm not clear on what you are actually saying here. But either way, it could be accomplished by simply moving the content (all or some) out after the merge has happened (assuming there is consensus to do that). The key, as I see it, is to get the information into one article so it can be worked on to reduce redundancy. The reason I said merging "Firefox version history" to "History of Firefox" is less "disruptive" is that for almost a full month now there have been notices posted at three different places (and briefy at a fourth) that users should discuss merging "Firefox version history" into "History of Firefox". No one has actually objected to that suggestion. Even you agreed that "if merger was still 'necessary' then I want to follow Dcljr's idea". So, I am prepared to (at some point in the near future) start actually doing the merge that I originally suggested. I believe that would be what an outside observer would expect to happen in this situation. Furthermore, "History of Firefox" is the older of the two articles, and, as you know, is actually the source of much of the information at "Firefox version history" (not counting when it was part of the "Mozilla Firefox" article, before 2005, because, let's face it, this info is never going back into the "Firefox" article), so this merge would simply be returning the info to where it came from originally. (Finally, regarding your earlier remark, "I think they looked fine separated": they cannot remain separated, because an article consisting only of the version-history tables will inevitably get AFD'd again.) - dcljr (talk) 06:44, 13 March 2019 (UTC)

I have performed the merge. Details are at #Merge done, below. - dcljr (talk) 22:29, 18 April 2019 (UTC)

@BD2412: I hope you do not think I have overstepped my bounds in "closing" this merge discussion and performing the merge. The discussion above did not seem to me to present a "blocking" objection. Since Rukario-sama did not reply to my last request for clarification (immediately above), I felt justified in doing the merge the way I originally proposed. - dcljr (talk) 22:41, 18 April 2019 (UTC)

Nevermind. I've undone the changes I made because I could not "finalize" the merge. - dcljr (talk) 09:38, 23 April 2019 (UTC)

BTW, I've left the merge notices in place, since the issue hasn't actually been resolved. - dcljr (talk) 11:37, 23 April 2019 (UTC)

Outdated version number

The recent stable version (as of 29 March 2019) is 66.0.2, not 66.0 as the article suggests. Do you need up to date information? Firefox itself will tell you the truth. Just go to Help -> About Firefox. Vikom ^talk 21:27, 29 March 2019 (UTC)

Merge done

Note to readers: The changes described in this comment have been undone. BTW, I probably should have used the section heading "Merge begun" instead of "Merge done". I was referring to the narrow sense of moving the text of one article into another. Obviously the merge was never completed. - dcljr (talk) 09:42, 23 April 2019 (UTC)

OK, I have gone ahead and performed the merge of Firefox version history into this article, as discussed (more or less) above. See my comments of 2 March and 13 March 2019 at #Merge version-history tables back to here for my reasoning about going ahead with the merge.

Now to explain what was actually done: First I copied the entire contents of the latest version of the "Firefox version history" article into this article, as recommended at WP:MERGETEXT, and then followed up immediately with a "proper" merged version that I've been working on locally on my computer. This should leave the article with no duplicate 'ref' names and no duplicate anchor names (as provided by {{anchor}} and "id=" attributes inside other elements). I have not, however, fixed any redundancy in the refs themselves (e.g., citations to the same source not collected under the same 'name='); this will take more work than I was willing to do before actually performing the merge. I will continue to work on the refs in the future, but other users can help, if they wish, now that the merge has been done.

I had to make quite a few changes that may affect how editors work on the article in the future: [Note: Deletions and insertions since I first posted this comment have been noted.]

1. All anchors of the form "Firefox 66.0.3" or "Firefox 60.2.2esr" "Firefox 60.2.2 ESR" that were in the "Firefox version history" (FVH) article have been converted to anchors of the form "66.0.3" or "60.2.2esr" for preserved in this article. These kinds of anchors lead to entries in the release-history tables. The removal of the "Firefox " prefix from these anchors is intended to remove clashes with anchors that were already in this article (addressed in the next item).
2. Anchors of the form "Version 60" or "Firefox 60" (no decimal points) that were already in this article are unchanged and still lead to paragraphs of running text describing those major versions. This The presense or absence of "decimal-point" sub-numbers makes it clear to editors (once they know the scheme, which is described in an HTML comment in the lead section) which intrapage links will lead to running text and which will lead to table entries. I hope that this can be kept consistent going forward.
3. Speaking of running text vs. table entries, there is now much duplication of information presented in these two ways in the article, so we need to decide whether and how the redundancy should be reduced.
4. The long list of links to "Current and future releases" that was near the top of FVH has been replaced by a less extensive running-text version in the lead section here that only references the most relevant versions. The anchors "Current and future releases", "Current supported official releases", "Current supported test releases", "Future official releases", and "Future test releases" (which were section titles in FVH) all lead to this paragraph in the lead section.
5. The "Future releases" anchor that led to the table for versions 70 and onwards at FVH is now a section containing info about all future versions (currently 67.0b1 onwards). As versions are released, the information will need to be moved from one table to another rather than simply changed in the same table, as was done at FVH.
6. I placed the "Release history" and "Early releases through version 4" anchors, which were section titles in FVH, in the "Phoenix 0.1 to Firebird 0.7" section here, since that is the first section that actually contains a release-history table.
7. Basically, all section headings in FVH should now be either section headings or anchors in this article.
8. All uses of {{anchor}} in section titles have been substituted, as recommended/explained at Template:Anchor#Examples. This leaves '<span…>' tags instead of '{{anchor…}}' template calls in the section-titles markup and leads to more a "stable" page history (i.e., if the anchors change) results in working section links in the page history.
9. The "Rapid releases" tables from FVH that used to be split "arbitrarily" at multiples of 10 are now split up in the same way as the "Version X–Y" sections of this article. There's one table per subsection under "Early versions" (except the 2 tables for the Phoenix and Firebird versions are in the same section), one table covering all versions 5 through 9 under the "Rapid release" section (which actually appears in the "Version 9" section), and one table per "Version X–Y" subsection under "Rapid release with ESR" (as with 5–9, the table for "Version 10–16" actually appears in the "Version 16" sub-subsection, and so forth).
10. All release-history tables are initially collapsed (so as not to overwhelm readers) except the one containing information about the currently supported versions, which is merely "collapsible". Once a table contains only "former" (not current) releases, the table can be "collapsed".
11. Because the tables are now collapsed/collapsible, I had to merge the "Legend" explaining the table-cell colors into the tables themselves (as the first and last rows — this is accomplished using labeled-section transclusion, as weas already being done at FVH). Tables of past versions that do not contain any color do not need the Legend, so I omitted it in those tables. Only the tables for current and future versions have the Legend. Thus the code containing the Legend will have to be moved from one table to the next when the older table contains only "former" releases (i.e., no colored cells).

I've probably forgotten something important, but those are the main changes that editors need to be aware of. Like I said, the refs need further work to fix any redundancies caused by the fact that they were originally in two separate articles. Apart from that, we need to decide how much redundancy we are willing to live with in the information presented in the paragraphs of text (which already existed in this article) and in the tables that just got merged in. - dcljr (talk) 22:20, 18 April 2019 (UTC)

Hmm. I'm rethinking my decision to use anchors like "66.0.3" for table rows. I can't make the change at this particular moment, but I'm strongly considering keeping (resurrecting) anchors like "Firefox 66" (no sub-numbers) for pointing at paragraphs of running text (i.e., section headings) and reserving anchor names like "Firefox 66.0" or "Firefox 66.0.1" (that have sub-numbers) for table rows. Probably will make this change later today. - dcljr (talk) 23:34, 18 April 2019 (UTC)

This is really far too much information here. We could perhaps split this article, or we could remove third-order updates. Onetwothreeip (talk) 01:10, 19 April 2019 (UTC)

Too much from what perspective? (Not trying to be argumentative, but I'm curious how you mean.) Although the new tables do make the page quite large in terms of bytes, most of the tables are collapsed, so the majority of the article will look pretty much the same to the reader (unless, of course, their browser does not collapse the tables), until they get to the large, uncollapsed table in the "Version 66" section. I don't think I would agree with splitting the article, although I'd be interested in hearing suggestions as to how that might be done. (Especially seeing as how versions 2, 3, 3.5, 3.6, and 4 already have their own articles.) As for how the size could be reduced otherwise, note that two months ago User:Rukario-sama removed all the past beta versions from the tables (see page history of FVH) and did some other work to streamline them a bit (e.g., removing an entire column from each table). I'm not sure removing all "third-order" updates would be a good idea, but perhaps simply changing the way the info is presented for them could help (for example, if all we're saying about a "patch" version is "Various security fixes" or "Various stability and regression fixes", do we need to say that at all? — or could all patch versions for the same minor version be combined somehow into a single table row?). Currently the "highlights" listed in the last column of the most recent release-history tables have essentially become a complete list of all changes noted in the sources. This info could be pared down quite a bit, especially once the tables get collapsed because they no longer contain any current releases — assuming that working links to Mozilla can be maintained to provide the full information to readers who are looking for it (note that website-archive.mozilla.org is now being linked to for old versions and www.mozilla.org for newer ones). Uh… yeah, those are my thoughts at the moment. - dcljr (talk) 06:56, 19 April 2019 (UTC)

Saying that it makes the page large is an understatement, this is Wikipedia's largest article. A simple way to split the article would be like versions 1 to 44 and 45 to 66. The content could be split and moved to the Firefox 2, 3, etc. articles since they are mostly small articles, or could form their own articles.

Additionally we can also remove or merge many of the third-order updates (like X.XX.XX), or are there fourth-order updates here as well? We could just remove patch updates and it seems you are implying there are third-order updates which are not patch updates or otherwise just minor fixes. Doing any of this could remove the need for splitting the article. We should recognise that you have created a very large addition to the article all at once, and I don't think that was a good idea. Onetwothreeip (talk) 08:17, 19 April 2019 (UTC)

Yeah, well, notice of the merge proposal was given in three different places — and briefly a fourth — and more than 2 months were allowed for discussion. No one said, don't merge the two articles into one. (And if you wanted to give your opinions on the merge proposal, you could have done so, as I all but invited you to do.) So anyway, the articles got merged. Because of the nature of the merge (merge with redirect), it had to be done all at once. The intention has always been to reduce the size of the article after the merge (as I have already stated multiple times). And we've both mentioned some ways of doing that. So don't worry so much about the present size of the article, as it will be changing.

Now, to address your questions directly: The only "fourth-order updates" are in the tables for versions 1.5 and 2. After that, the deepest it goes are third-level "patch" releases (like 66.0.2), which are by definition minor stability and/or bug fixes. The main reason I suggest keeping those is that many readers coming for the tables (at first, largely through the "Firefox version history" redirect) will be looking for information about the latest releases, which most of the time will be the patch releases. As I said before, this info can be condensed quite a bit by simply removing redundant stuff. The version numbers, dates, and ref links should stay in the table(s) for the most recent versions, at least. If they must be removed eventually, some kind of "schedule" for doing this can be discussed later (like keeping them for two ESR cycles before removing, or something).

As for your splitting suggestion, I don't see a "logical" rationale for splitting it at version 45 — at least not one that would continue to apply after a few more tables are created here (the next few ESR releases). If a split is really needed, the most logical place (IMO) would be at version 10, when ESR started. That would imply two separate "History" articles, one for "Early history of Firefox" (or whatever) and one for, well, whatever you would call the second article.

As for moving the info for pre-5 versions into those articles, that's not a terrible idea, but it won't work for the versions that don't have their own articles, namely everything before 2.0 (the Phoenix and Firebird versions, 1.0, and 1.5). Also, are you suggesting we move the tables into the other articles and transclude them back to here, or not have them here at all? (In which case, there will be an odd asymmetry in how versions are treated in this article.)

Bottom line for me is this: let's first address the high levels of redundancy in the article before doing any splitting, moving or wholesale removal of info. That has always been the post-merge plan. After that, we can consider removing old, "less necessary" information. And then as a "last resort", we can consider splitting/moving to other articles. That's my suggestion. And finally, just to make this explicit: I do plan to start the first-stage "redundancy" work myself — it's not like I was planning to just wait around for others to take care of it. Just give me a minute… [grin] - dcljr (talk) 10:47, 19 April 2019 (UTC)

I'm not sure why you're saying that there were notices of such discussion for.

At version 45 is an example of splitting at any particular point, not necessarily at 45. We could split at version 10 but there would probably still need to be a split somewhere between 10 and now.

If there are not articles for certain versions, we could place the content at the closest appropriate article or leave that content here. I'm not suggesting transclude anything, I don't see the necessity for that.

What information are you saying is redundant? Just to be clear, I don't have particular preference for either splitting or reducing and I agree that we should see what can be reduced first. Onetwothreeip (talk) 22:52, 19 April 2019 (UTC)

Hey Dcljr, what information do you think is redundant in this article? Cheers. Onetwothreeip (talk) 00:50, 22 April 2019 (UTC)

[edit conflict] To just take one example, read the text in the "Version 60 (ESR)" section and compare it to the information in the table rows for Firefox 60.0 and Firefox 60.0 ESR (and then consider the same for 60.0.1 / 60.0.1 ESR and 60.0.2 / 60.0.2 ESR). Many of the software changes are described in all three places, in some cases using the exact same wording. This is what I was alluding to in item #3 in my original post in this section ("Speaking of running text vs. table entries…"). The redundancy in the paragraphs of text and the table rows is the result of the same info being added to two separate articles; the redundancy in the table rows for the non-ESR and ESR versions obviously already existed in the FVH article before the merge. We need to consider the best way to reduce both types of redundancy, and whether that solution should favor keeping the descriptions of software changes in the running text or favor presenting that info in the tables, possibly refactored in some way. It might be tempting to conclude immediately that the tables are simply unnecessary (as they duplicate what's in the text) and should therefore be removed. That may well be the best solution in the end, but I can't say for sure right now, because I haven't had the chance to carefully "study" the situation. The other kind of redundancy that I alluded to above (in the final paragraph of my original post) is the duplicated information in 'ref' tags that used to be citing the same source in the two separate articles but are now in the same article and so can take advantage of named refs (for example, references 769 and 823). That problem is much more straightforward to fix but just takes time. - dcljr (talk) 09:41, 22 April 2019 (UTC)

@Dcljr: Why on Earth did you do that? This article now has 482,702 bytes of wiki-markup, and is now Wikipedia's largest. Please reverse your actions, ASAP. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:38, 22 April 2019 (UTC)

Have you actually read the discussion up to this point or is this simply a knee-jerk reaction to the current size of the article? The answer to your question has already been given in the comments above. The short version is this: the content that was merged to here used to be in its own article that was considered for deletion and then for merging. Because it was not clear what content from the other article was ultimately going to remain here, the entire content of the other article was merged to here to satisfy licensing terms and then edited down a bit into a form where all the info could exist without any errors. Now the content is about to be edited down quite a bit further to reduce the great amount of redundancy in the information that was in the two articles when they were separate (which is one good reason they needed to be merged). That may not be happening with the speed you would like, but undoing what has already been done is not going to make it happen any faster. If you have not already done so, please carefully read my comments at #Merge version-history tables back to here and in this section for more information and context. As I have already been telling Onetwothreeip, the current size of the article is not the intended final size of this article. And now I have spent a couple of hours yet again this evening typing up talk page comments instead of actually working on the article.... - dcljr (talk) 10:07, 22 April 2019 (UTC)

It's very strange to say that what you've added into the article is not intended to stay in the article. Why not just only add content that you intend not to delete a few days later? Also, can you tell us clearly what content you intend to remove? It wasn't clear at all. Given that you're admitting the content shouldn't stay in the article, anybody would be justified to remove the content you added that has made this article the largest article on Wikipedia. Onetwothreeip (talk) 10:24, 22 April 2019 (UTC)

Did you miss this: Please reverse your actions, ASAP.? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:27, 22 April 2019 (UTC)

@Pigsonthewing: Did you miss my reply? Because I notice you didn't bother responding to it in any useful way. When a user questions a request you have made of them, "Respect mah authoritah!" is not a helpful response. - dcljr (talk) 09:34, 23 April 2019 (UTC)

OK, well, I have just reverted my changes to all four relevant pages (History of Firefox, Firefox version history, Talk:History of Firefox, Talk:Firefox version history), undoing the merge process I had started. The main reason I've done this is because it's become clear that I don't have the huge amount of free time it would take to complete the merging of these two articles (even if I knew exactly what form the final product should take, which, frankly, still isn't really the case). When I started, I had hoped to complete the merge in a matter of days, or a week. It's now obvious that it would take far longer than that. If anyone reading this is interested in giving it another shot, my versions are, of course, still in the page history. I warn you, though: it's going to be nearly impossible without some form of automation (i.e., text-processing programming). Because of this, I expect that no one will actually do anything to remedy the fact that the two articles share such a large amount of information (but one is not simply a subset of the other), until Firefox version history inevitably gets AFD'd again (perhaps repeatedly) and eventually just disappears. Oh, well… right? - dcljr (talk) 09:34, 23 April 2019 (UTC)

I've reinstated the merger, although done differently. I hope you're okay with what I did, that I merged History of Firefox into Firefox version history. Rukario-sama ^ㅈ^ -(...) 00:24, 6 May 2019 (UTC)

Yeah, I guess no one has a problem with it. I haven't checked to see the details of what you did. I notice no one is bitching about it because it didn't create the largest Wikipedia article. Because, you know, that would have been Bad… - dcljr (talk) 02:12, 20 May 2019 (UTC)