I tend to see these new "releases" as "builds". Nothing more than that. I do not like this whole "rapid schedule" hype. Yet, it is what it is.
Now, maybe we can take a different approach. We will upgrade not to every new release, but use a different schedule. Say every 2 or 3 releases? Another option is, as Andrew suggested, just to stay with 3.6 ( in other words) - with upstream vendor. This approach kills a few birds with one stone. As a user I don't see why I have to move to a new (4+) versions. Till last night I used stock versions wo problems. I do understand that ill be screamed at by web developers now :) just 2c. Andrew -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Dr Andrew C Aitchison <a.c.aitchi...@dpmms.cam.ac.uk> wrote: On Sat, 3 Sep 2011, Tom H wrote: > On Sat, Sep 3, 2011 at 10:57 AM, Andrew Z <form...@gmail.com> wrote: >> Tom H <tomh0...@gmail.com> wrote: >>> On Sat, Sep 3, 2011 at 1:16 AM, Todd And Margo Chester >>> <toddandma...@gmail.com> wrote: >>>> >>>> If any of you are still running 64 bit firefox4 from Fedora people on >>>> sl6.x, >>>> >>>> http://repos.fedorapeople.org/repos/leigh123linux/firefox4/epel-6/x86_64/ >>>> (which has been taken down) >>> >>> Have you read >>> http://repos.fedorapeople.org/repos/leigh123linux/firefox4/readme >> >> So what do we use instead ? I was going to upgrade to 4 this wknd... > > The same person has also packaged FF5 and FF6 for EL6 > http://repos.fedorapeople.org/repos/leigh123linux/ > > I don't know for how much longer he's going to be able to package > newer and newer FF versions that'll be compatible with SL6 but here's > the Mozilla schedule. FF7'll be out at teh end of September. There > are no EOLs listed though. > > https://wiki.mozilla.org/RapidRelease/Calendar EOLs are mentioned at the end of https://wiki.mozilla.org/RapidRelease ----- This section clarifies some questions that have come up about the relationship between Firefox 4 and older and Firefox 5. * 5.0 and newer processes will not be "backported" onto 4.0.x and older releases * there will be 4.0.x releases and chemspill handling o branch team is taking over for 4.0.1 * there will be 3.6.x and 3.5.x releases and chemspill handling End-of-Life: * As part of the faster cadence, FF5.0 automatically EOL's when FF6.0 is released with users getting silent updates. * For the previous FF4.0.x, FF3.6.x, FF3.5.x releases, we had different policy in place at the time of release. While there were problems with the previous policy, we still need to respect other projects (and the users) that still depend on these older code lines. * We need a working policy for when to end-of-life these 3 older release branches o how much longer do we plan to generate security releases for these? o what is the deciding metric to use to cutoff? By time? by "number of users remaining"? By "% of overall userbase"? o any metric that measures number of users remaining needs to also include specific cadence for prompted/advertised Major Updates. ----- Thus each firefox is EOL as soon as a newer major release comes out, ie each released firefox is EOL six weeks after it is released. FF3 is special since it was released Looking at http://www.mozilla.org/security/known-vulnerabilities/firefox.html http://www.mozilla.org/security/known-vulnerabilities/firefox35.html http://www.mozilla.org/security/known-vulnerabilities/firefox36.html I see that the Digitar certificates patch went into 3.6.21 and 6.0.1 but no ff4 or ff5 appears to have been patched, nor any 3.5, which supports the "EOL six weeks after release" theory. I think our options are to return to Firefox 3.6, accept the six week churn or find another browser. Most unsatisfactory. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge a.c.aitchi...@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
