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).
Snuffleupagus
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)?
Snuffleupagus
on 4 Mar 2018
I edited the first post to include a reference to #9528. The documentation should be updated before the official 2.0 release.
Rob--W
on 5 Mar 2018
I have also updated the project board at https://github.com/mozilla/pdf.js/projects/5 with all changes that we need to make.
timvandermeij
on 5 Mar 2018
Anything I can do to help with this?
prohtex
on 10 Mar 2018
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?
Rob--W
on 22 Mar 2018
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!
timvandermeij
on 3 Apr 2018
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.
wojtekmaj
on 3 Apr 2018
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.
timvandermeij
on 3 Apr 2018
Actually, yes it will! :D
wojtekmaj
on 3 Apr 2018
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).
timvandermeij
on 3 Apr 2018
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 :)
wojtekmaj
on 4 Apr 2018
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?
brendandahl
on 13 Apr 2018
async/await with babel worked for me just fine on IE11 if you included babel-polyfill, along with proper config of course.
wojtekmaj
on 13 Apr 2018
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).
Rob--W
on 13 Apr 2018
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.
prohtex
on 19 Apr 2018
+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.
tonyjin
on 20 Apr 2018
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
on 27 Apr 2018
@kekkc makes a lot of sense to me.
prohtex
on 27 Apr 2018
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?
prohtex
on 1 May 2018
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.
prohtex
on 13 Jun 2018
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!
timvandermeij
on 13 Jun 2018
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.
timvandermeij
on 13 Jun 2018
This is thrilling. Thanks to everyone who worked so hard on 2.0.
prohtex
on 13 Jun 2018
@timvandermeij When does the next iteration start? Or could we expect 2.0.550 to be released as latest ("non-beta") on npm?
wojtekmaj
on 10 Sep 2018
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
on 10 Sep 2018
@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.
haf
on 23 Sep 2018
Monthly check-in here. Can I do anything to help?
haf
on 25 Oct 2018
The stable version is being prepared: #10181.
timvandermeij
on 25 Oct 2018
Related issues
dmisdm
路
3Comments
zerr0s
路
3Comments
BrennanDuffey
路
3Comments
anggikolo11
路
3Comments
jigskpatel
路
3Comments
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.