Pdf.js: Offically release version 2.0

Created on 28 Feb 2018  ·  28Comments  ·  Source: mozilla/pdf.js

Before landing any larger (pending) PRs, it'd be a good idea to officially release version 2.0.x of PDF.js first to reduce the regression risk in the initial release based on the 2.0 branch.

Remaining TODOs:

  • [x] Merge PR #9520.
  • [x] Merge PR #9493.
  • [x] Update documentation (#9528).
1-other

Most helpful comment

+1 for keeping IE11 support, at least via transpilation. Lots of enterprise users, especially those in Asian countries must use IE11 due to corporate policies.

All 28 comments

@yurydelendik Since I'm not really familiar with all the details of https://github.com/mozilla/pdf.js/wiki/Release-Process, could you please help create a new PDF.js pre-release for version 2.0.419 (i.e. at commit c33bf800cc87941cc681c3c54279ab1b9745650d)?

I edited the first post to include a reference to #9528. The documentation should be updated before the official 2.0 release.

I have also updated the project board at https://github.com/mozilla/pdf.js/projects/5 with all changes that we need to make.

Anything I can do to help with this?

There are no blocking issues any more in the code (the JSFiddle examples are hosted elsewhere). Can we release 2.0 now? Anyone volunteering to write a migration guide for PDF.js 1.x code to 2.x?

I have updated the browser support section of the FAQ page, which solved one of the tasks we had left. I have also updated https://github.com/mozilla/pdf.js/projects/5 to show the current status of release 2.0. The migration guide is added and one PR that contains an API change that I think we should put into 2.0 to avoid API changes in later versions (since version 2.0 changes the API already anyway).

If anyone is willing to help out with the tasks on the project page, please feel free to do so. Put a comment here so we know you're working on it. Hopefully we can finish version 2.0 soon this way. Thanks!

Regarding "Audit the existing CSS, and remove no longer needed (prefixed) rules", have you considered removing them all completely and using autoprefixer to target specific browsers as needed, on build? Auditing that seems like a lot of work that could be automated.

I don't think I've seen that come by before, but it sounds like a good idea. However, I'm a bit worried about cases such as #6685. Would those be covered by such a module too, or would we still have to do that ourselves? If we were to use such a module, a comparison before/after should be made to ensure nothing changes from a functional point of view.

Actually, yes it will! :D

obraz

In that case, if anyone is willing to give Autoprefixer integration for PDF.js a shot, then please feel free to do so so we can test it. It might even fix some open issues given the comment above, which would be great (aside from the reduced maintenance work).

Someone was willing :) https://github.com/mozilla/pdf.js/pull/9629
Needs some configuration (list of supported browsers) and then testing (comparing CSS outputs mostly), other than that, fully functional :)

I'd like to propose one more thing for 2.0, dropping support for IE11. This would give us async/await which I've found to be immensely helpful in code readability. We could do async/await with babel, but in the past I haven't had much success using the plugin.
Thoughts?

async/await with babel worked for me just fine on IE11 if you included babel-polyfill, along with proper config of course.

IE 11 browser usage is still relatively high (2.76% according to https://caniuse.com/usage-table), so I would not drop IE 11 yet. We can already start using async/await for code readability, and transpile if desired.

Also, Chrome 49 does not support async/await, and Chrome 49 is still supported by the extension because it is the last version of Chrome that runs on XP (which has relatively high usage numbers too (considering its unsupported status...) - see #9397).

Can anyone provide steps to check out a working beta of the 2.0 release? Is the scrolling modes PR a part of the initial release or would that have to be merged on top of the 2.0 release? I need to implement scrolling modes on a number of sites and am looking to do so in a way that will be most easily kept up-to-date with future releases.

+1 for keeping IE11 support, at least via transpilation. Lots of enterprise users, especially those in Asian countries must use IE11 due to corporate policies.

Is the scrolling modes PR a part of the initial release or would that have to be merged on top of the 2.0 release?

https://github.com/mozilla/pdf.js/pull/9208 was ready 2 months ago. Maybe it would make sense to merge this directly and include it v2.0. Until v2.0 is released there should be enough time to test this productively even longer.

@kekkc makes a lot of sense to me.

Guys, what can other members of this community do to contribute meaningfully to this project? Is there any kind of timeframe for the 2.0 release? I have 6 active sites running pdfjs, and every one is a cobbled together version using code copy and pasted from many tickets here on GitHub. Nothing seems to make its way into the base branch in a timely fashion. I'm now doing yet another frankenstein deployment for a new site so I can implement the elegant and completely finished scrolling modes solution created by @rhendric. What can I do to help with the release?

Would it be possible for someone to update those of us who are waiting for the 2.0 release with some information about what remains to be done? Looking over the outstanding issues, they all seem trivial or already resolved.

The pre-release of version 2 is done and available from https://github.com/mozilla/pdf.js/releases/tag/2.0.550. No major API changes are planned, so if no blocking issues are found then that will become the final version 2 release.

It did take quite a bit of time to get version 2 ready for release because of limited developer availability and other issues that needed to be fixed, so this pre-release is really a milestone. Thank you for bearing with us and providing constructive feedback!

I'm closing this issue since the pre-release is done (which will become the full release in the next iteration) and the remaining work is listed on the project board.

This is thrilling. Thanks to everyone who worked so hard on 2.0.

@timvandermeij When does the next iteration start? Or could we expect 2.0.550 to be released as latest ("non-beta") on npm?

From the pre-release we identified and fixed some regressions. Moreover, some performance and font conversion improvements have landed. We're tracking the final release on the project board. However, you can expect the pre-release to be replaced by the final release because of the regressions, so we don't want to ship the pre-release as the final release.

I think we have merged everything we wanted for 2.0, so we should be able to make the final release soon. @brendandahl Would you have time to make this release? After that, we can take care of compiling a changelog.

@timvandermeij @brendandahl When do you think this can be released so that downstream consumers can update their dependencies? If you are code-complete, but still want to test something; can you release a release candidate meanwhile? Thank you.

Monthly check-in here. Can I do anything to help?

The stable version is being prepared: #10181.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

azetutu picture azetutu  ·  4Comments

liuzhen2008 picture liuzhen2008  ·  4Comments

xingxiaoyiyio picture xingxiaoyiyio  ·  3Comments

smit-modi picture smit-modi  ·  3Comments

anggikolo11 picture anggikolo11  ·  3Comments