https://github.com/mozilla/pdfjs-dist et https://www.npmjs.com/package/pdfjs-dist ne montrent pas clairement que la version est une version continue. La documentation, provenant de https://github.com/mozilla/pdf.js/blob/a7c35025fed8beb8f9b93688fff40497c7ad2de0/external/dist/README.md devrait probablement être modifiée pour que cela soit plus clair. Et https://mozilla.github.io/pdf.js/getting_started/ n'indique pas clairement que pdfjs-dist n'est pas la version stable.
Voici un exemple de confusion causée par cela : https://github.com/mozilla/pdf.js/pull/9385#issuecomment -363030784
Ou nous pourrions envoyer des versions de npm à la place.
versions npm, s'il vous plaît ! J'utiliserais la balise next
pour toutes les versions bêta et aucune balise pour les versions stables. À peu près la norme de l'industrie pour le moment.
J'ai travaillé à ce sujet sur https://github.com/mozilla/botio-files-pdfjs/pull/22.
Une chose que je ne sais pas comment gérer est de réparer notre configuration actuelle de npm. Je pense que je vais réétiqueter la branche 2.0 en tant que next
et publier une ancienne version 1.0 comme stable jusqu'à notre sortie. Cela peut cependant conduire à une certaine bizarrerie pour quiconque a déjà extrait une version 2.0 de npm. Ouvert aux suggestions !
Je ne peux pas répondre pour l'ensemble de la communauté mais à mon avis, le changement vaut bien cette agitation ponctuelle.
Je pense que c'est effectivement la meilleure solution ici. De plus, si nous publions la version 2.0 finale, elle aura un numéro de version plus élevé, donc je pense (mais je peux me tromper ici car je ne suis pas si proche du fonctionnement interne de NPM) que les personnes qui ont tiré une version précédente puis automatiquement mis à niveau vers la version 2.0 finale.
Oh oui. Nous pouvons simplement marquer les versions non finales avec next
au lieu de latest
partir de la version 2.0 officielle. Alors:
^1.x.xxx
seront toujours sur la dernière pré-version 1.x publiée - aucun changement^2.x.xxx
recevront la version stable 2.0 finale et cesseront de recevoir les pré-versionslatest
recevront la version stable 2.0 finale et cesseront de recevoir les versions préliminairesC'est donc plutôt gentil OMI.
Nous pourrions également donner aux personnes du point 1 bloquées sur la pré-version 1.x un indice en utilisant npm deprecate en dépréciant toutes les pré-versions 1.x avec un message comme "Vous utilisez probablement sans le savoir une version instable de PDF.js. Veuillez rétrograder à la dernière version stable, 1.9.xxx ou mise à niveau vers la toute nouvelle version 2.x. Guide de mise à niveau ici : http://example.com/pdfjsupgradeguide ".
Le changement pour les bots est maintenant fusionné.
@brendandahl Y a-t-il autre chose à faire pour ce problème, à part peut-être un redémarrage du bot/un webhook ?
Où cela se trouve-t-il ? J'espère vraiment une version compatible avec le webpack 4 bientôt.
On dirait que c'est fait
Oui, le référentiel pdfjs-dist
n'est plus modifié après chaque commit. Je ne sais pas si le processus de publication fonctionnait correctement. @brendandahl N'avez-vous pas rencontré de problèmes lors de la création de la pré-version ? S'il y a des problèmes, ils doivent être résolus car si la pré-version devient la version finale, elle doit également être publiée dans pdfjs-dist
.
@timvandermeij
avez-vous un plan quand sortirez-vous pour la 2.0 ? y a-t-il des problèmes restants concernant la 2.0 ? https://github.com/mozilla/pdf.js/projects/5
@banyan Vous pouvez l'utiliser maintenant :
https://github.com/mozilla/pdf.js/releases/tag/2.0.550
@prohtex , c'est clairement marqué comme une pré-version.
@wojtekmaj N'a pas dit que ce n'était pas une pré-sortie. On m'a dit que ce serait plus ou moins fonctionnellement la même chose que la version. Étant donné qu'il est très difficile de trouver ce lien, j'ai pensé le partager.
Fermeture puisque c'est fait.
Commentaire le plus utile
Où cela se trouve-t-il ? J'espère vraiment une version compatible avec le webpack 4 bientôt.