Updated Frequently Asked Questions (markdown)

Thorben Bochenek 2014-04-29 06:31:19 -07:00
parent 8565e96207
commit 5b1bb9cd65

@ -155,4 +155,4 @@ The version number consists of three digits: the major release number, minor rel
We are moving fast and trying to land as much good stuff as we can review and test. The [generic viewer](http://mzl.la/pdf-js) and development of version of Firefox PDF Viewer [extension](http://mzl.la/pdf-xpi) always contain the latest PDF.js build and available for testing.
During cooldown period, about once or twice in 6 weeks, we push our library to the [Firefox Nightly](http://nightly.mozilla.org/) channel. We decided to tag/mark our master branch each time we do that, and at this point a beta release is created. To promote a latest beta to a stable release, we listen for a feedback (via [github](https://github.com/mozilla/pdf.js/issues), [bugzilla](https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=PDF+Viewer), [mailing list](https://lists.mozilla.org/listinfo/dev-pdf-js), or [IRC](irc://irc.mozilla.org/%23pdfjs)) from the users and projects that use PDF.js library. If no critical issues (e.g. a build is unusable, majority of the documents cannot be rendered, etc.) appeared, we promote the build as stable. Otherwise we either discard the release by replacing it by new beta or redo the build with commits that will fix a critical issue.
During cooldown period, about once or twice in 6 weeks, we push our library to the [Firefox Nightly](http://nightly.mozilla.org/) channel. We decided to tag/mark our master branch each time we do that, and at this point a beta release is created. To promote a latest beta to a stable release, we listen for feedback (via [github](https://github.com/mozilla/pdf.js/issues), [bugzilla](https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=PDF+Viewer), [mailing list](https://lists.mozilla.org/listinfo/dev-pdf-js), or [IRC](irc://irc.mozilla.org/%23pdfjs)) from the users and projects that use PDF.js library. If no critical issues (e.g. a build is unusable, majority of the documents cannot be rendered, etc.) appeared, we promote the build as stable. Otherwise we either discard the release by replacing it by new beta or redo the build with commits that will fix a critical issue.