Je suis toujours en faveur de la publication d'une version de correction de bogues plus petite le plus tôt possible. Je préfère la sortie de style Django

Il y a au moins une nouvelle fonctionnalité dans le maître https://github.com/celery/celery/commit/0d5b840af1890a9a499a339aa3256445b43837dc
Nous devrons sélectionner toutes les corrections de bogues.

Je veux vraiment sortir une nouvelle version avec https://github.com/celery/celery/pull/4358 mais elle a besoin d'une couverture de test.

@thedrow Je suggérerais que nous

Ouais faisons ça.

@georgepsarakis Des mises à jour sur 4.2 ? Les corrections de bugs heure/fuseau horaire/eta semblent critiques...

Il y a un PR que nous devons fusionner, ce qui provoque des fuites de mémoire lors de l'utilisation du backend des résultats Redis.
Vérifiez que le jalon est un pour le progrès. Nous y sommes presque.

Pour info, je me marie le 28 décembre donc je ne pense pas que nous pourrons sortir avant ça.
J'aimerais qu'on sorte un communiqué d'ici le 7 janvier.
@georgepsarakis @auvipy Veuillez préparer un PR continu avec les notes de version pour pyamqp, kombu et céleri avant cela.

@Fokko @johnarnold Si vous souhaitez aider, nous avons encore 4 demandes d'extraction qui nécessitent une couverture de test et/ou un rebasage avant la sortie 4.2.

Je viens d'ajouter le #4369 au jalon 4.2 car je pense que je pourrai y arriver dans la semaine prochaine.

Le jalon 4.2 est passé à sa date d'échéance et plusieurs problèmes sont toujours ouverts (les numéros 33/98 sont toujours ouverts (33 %)).
Je suis nouveau sur le projet et j'ai donc une question à ce sujet.

Habituellement, les projets utilisent l'un des deux modèles, en ce qui concerne les jalons, soit :

1. Repousser la date d'échéance jusqu'à ce que tous les problèmes liés aux jalons aient été résolus, ou
2. Libérer tout ce qui est prêt à la date d'échéance et couper le reste ?

Quelle est l'approche de Celery pour les jalons ?

Le seul bloqueur de la version actuellement est https://github.com/celery/celery/issues/4423 car nous avons ajouté une nouvelle fonctionnalité qui nécessite une documentation.
@georgepsarakis Pouvez-vous commencer à travailler sur les notes de version s'il vous plaît ?

@thedrow, je vais essayer de le démarrer sous peu.

j'ai mis à jour les problèmes de jalon

@auvipy @thedrow si possible,

https://github.com/celery/celery/pull/4481 une dernière fusion. et verrouillé

Nous devrions terminer le #4423 avant la sortie mais cela ne s'applique pas aux notes de publication.

J'adorerais voir cela sortir bientôt. Je viens de passer du temps à essayer de comprendre pourquoi les tentatives automatiques ne fonctionnaient pas (#4341).

Il y aurait un problème avec master après (probablement) la fusion de ce PR :

• https://github.com/celery/celery/issues/4498
• https://github.com/celery/celery/issues/4041

Où voyez-vous les rapports concernant le maître ?

Dans le #4498 :

Comportement prévisible
Sur la branche master, cela ne fonctionne pas du tout. Vous obtenez ceci :

Et dans https://github.com/celery/celery/issues/4041#issuecomment -359845025

@georgepsarakis cette erreur se produit lorsque la méthode est appelée à partir de l'objet Class, au lieu d'une instance... je suppose que ce problème se produit lorsque apply_async est appelé sur des tâches non liées (je ne l'ai pas encore confirmé).

EDIT cela semble se produire lorsque l'héritage est utilisé à la place du décorateur de tâche :
python class AddTask(Task): def run(self, *args, **kwargs) # ...
vs.
python @app.task() def add_task(*args, **kwargs): # ...

Quelqu'un s'attaque-t-il aux bloqueurs de version ?

Je ne vais pas lâcher une régression dans la nature. Peut-être devrions-nous annuler le changement incriminé et recréer le PR ?

c'est en fait un très vieux problème https://github.com/celery/celery/issues/3723 plz check

Je parlais des #4198 et #4041 que @georgepsarakis a mentionnés.
Si je me trompe, ce n'est pas un bloqueur et nous devons fermer les problèmes en tant que doublons.

On dirait que j'ai parlé trop tôt du #4041. Devrions-nous essayer d'exécuter le dernier maître pour voir si les problèmes sont entièrement résolus ?

Je vous en prie.

Il semble toujours être cassé pour les tâches cron. Il y a aussi ce qui semble être une très petite fuite de stockage Redis.

Le problème https://github.com/celery/celery/issues/3808 est également toujours en panne pour moi sur le maître.

Je parierais que le correctif pour #3723 serait assez petit si quelqu'un ayant des connaissances internes sur le céleri pouvait y jeter un œil. C'est facile à reproduire.

Malheureusement, je n'ai pas assez creusé tout seul...

3808 ont un jalon 5.0 . Idem avec #3723

Le seul qui reste avant la sortie si nous suivons le jalon (https://github.com/celery/celery/milestone/19) est le #4423

Les jalons sont-ils incorrects ?

J'ai mis à jour le jalon

@auvipy @georgepsarakis @thedrow @ask

4041 ne fait aucun progrès et bloque la publication d'une tonne d'autres correctifs. S'il s'agit d'un bug préexistant et non d'une régression, pouvons-nous obtenir une version de ce qui est déjà fait ?

@johnarnold Il y a une régression que nous devons corriger ou annuler https://github.com/celery/celery/issues/4041#issuecomment -359875276 et un autre problème qui n'est pas encore clair s'il est causé par Celery 4.2.
Nous devons d'abord corriger la régression et voir si nous pouvons toujours reproduire le problème sur Celery 4.2.

le problème ne se produit qu'avec l'ancien style Task/PeriodicTask - voir #4572

Compte tenu de la taille de cette version, serait-il judicieux de faire une pré-version alpha/bêta assez rapidement ? Je pense que cela permettrait à certains utilisateurs de faire plus de tests dans le monde réel ? Je serais heureux de mettre une version alpha sur nos systèmes de test !

D'un autre côté, j'apprécie que cela représente du travail pour les mainteneurs, alors n'hésitez pas à dire non

Je pense que nous allons commencer par une version bêta, oui.

ce sera génial

@thedrow @auvipy dites -moi si vous voulez que je reprenne les efforts sur le Changelog. Je suis d'accord pour qu'une libération ait lieu dans les plus brefs délais. Il semble qu'avec #4572 , #4041 pourrait en fait être corrigé.

oui s'il vous plaît reprendre le travail sur changelog

@auvipy @thedrow Je vais probablement soumettre une Pull Request aujourd'hui.

@thedrow y a-t-il quelque chose en attente pour la sortie ? Si vous avez besoin d'aide, faites le moi savoir.

J'ai écrit l'annonce de sortie hier. Je vais taguer aujourd'hui.

Il s'avère que nous manquons de documentation appropriée pour le backend des résultats Redis Sentinel.
Ce n'est pas un bloqueur pour la sortie puisque nous allons d'abord publier une RC mais ouvrons un problème à ce sujet et réparons-le avant GA.

Je viens de publier 3.1.26 contenant https://github.com/celery/celery/pull/4357.
Ce correctif est crucial pour que les gens migrent vers Celery 4.x, j'ai donc créé une version 3.x spéciale juste pour cela.

Le premier RC est sorti.
Je créerai des problèmes pour les bloqueurs de documentation plus tard, peut-être demain.

vous avez peut-être oublié les versions de pyamqp et kombu ?

Je n'ai pas. Je n'ai juste pas eu le temps d'y arriver. Je dois également préparer les notes de version pour eux.

Oh pardon. merci pour le rc. après avoir poussé d'autres packages, informez-moi de l'annonce d'un article de blog

Il s'avère que nous avons un problème de compatibilité avec Flower car nous avons sorti une RC. Voir https://github.com/mher/flower/issues/791
C'est une solution très facile. Des volontaires?

a essayé: https://github.com/mher/flower/pull/792; Dites-moi ce que vous en pensez

Je viens de sortir Celery 4.2.0RC2.

Merci! pouvons-nous nous attendre à la nouvelle version des autres dépendances si vous pouviez gérer le temps bien sûr

Si quelqu'un fait les notes de version, je peux les publier.

@thedrow Pouvons-nous obtenir une version finale ?

Il y a quelques choses que je veux corriger en premier. Je créerai une liste de contrôle plus tard et attribuerai des tâches.

Bonjour, merci pour la nouvelle version.

Je l'installe : pip install celery==4.2.0RC2
je le lance :
celery -A app worker -l info --beat => celery<strong i="10">@mountain</strong> v4.2.0rc2
celery -A app beat -l info -S django => scheduler -> django_celery_beat.schedulers.DatabaseScheduler

Mais le planificateur envoie toujours les anciennes tâches qui ont été supprimées des entrées de tâches périodiques.

Il semble que #3812 puisse être reproduit avec https://github.com/celery/celery/issues/3812#issuecomment-381554599 .
Nous allons corriger cela avant l'AG si c'est vraiment le cas.

J'ai sorti notre dernière RC. Si aucun problème n'est trouvé, nous publierons le GA bientôt.
La seule chose qui manque vraiment maintenant est le document de processus de publication et #4679.

Hey tout le monde.
J'essaie de m'impliquer davantage dans le projet.
Y a-t-il quelque chose que je puisse aider pour la prochaine version ?
Merci.

Bonjour @xirdneh . Vous pouvez contribuer de plusieurs manières :

• Le journal des modifications de Kombu pour 4.2 n'a pas encore été construit, je pense : https://github.com/celery/kombu/issues/849
• Le changelog de céleri peut ne pas être finalisé aussi
• Nous avons un changement de documentation requis et en attente : https://github.com/celery/celery/issues/4721
• La version stable dépend également de la résolution de https://github.com/celery/celery/issues/4731
• Testez la version RC3 en bêta (par exemple sur votre environnement de pré-production) si vous avez la capacité et le temps de le faire.

Faites-moi savoir si vous avez besoin de plus de conseils et d'aide, merci!

Impressionnant,
Je vais voir ce que je peux faire pour le #4731 et la documentation.
Merci.

Notez que j'ai sorti Kombu 4.2 qui casse Celery 4.1.0.
Je vais bientôt publier une version de correction de bugs. Si vous utilisez toujours Celery 4.1.0, je vous invite à mettre à niveau dès que possible.

J'ai publié 4.1.1 et j'exhorte tout le monde à mettre à jour.
@auvipy Veuillez publier un article de blog à ce sujet.

Est-il possible d'obtenir des autorisations sur le canal IRC Freenode #celery pour changer de sujet ?
Certaines personnes sont confuses au sujet du versioning et je peux le garder à jour.
Mon identifiant IRC est josuebc
Merci.

peut-on sortir une autre RC ?

@xirdneh, je devrai envoyer un ping à
Pouvez-vous ouvrir un nouveau numéro ?
@auvipy Oui, bien sûr.

Je viens de sortir Celery 4.2.0RC4.
Nous devons encore résoudre les #4731 et #4721 pour libérer GA.

https://github.com/celery/celery/pull/4762 correctifs # 4731

Nouveau bloqueur #4768 :(

Je viens de sortir amqp 2.3.0.
Veuillez le tester et nous faire savoir s'il y a des problèmes.

@thedrow également possible bloqueur https://github.com/celery/celery/pull/4770#issuecomment -392419237

On dirait un.
Dommage que nous l'ayons attrapé si tard.
Des volontaires pour réparer ça ? Je publierai une version Bugfix.

J'ai publié le correctif dans amqp 2.3.1.

Le #4768 est-il le seul bloqueur maintenant ?
Quelqu'un prend ça ?
J'aurai un peu de temps pour le prendre ce week-end si personne d'autre n'a le temps.

s'il vous plaît regardez-le

Peut-être un bloqueur : https://github.com/celery/celery/issues/4791
Je pourrai probablement finir d'écrire les tests lundi.

J'ai fusionné le dernier PR.
En ce qui me concerne, le maître est maintenant gelé.

Je vais terminer les notes de version et publier aujourd'hui.

oui s'il te plait :dagger:

Impressionnant!
:métal:

Publié! :tada:
Il reste quelques choses à faire :
Nous devons publier une annonce sur notre site Web et nous assurer que le site Web de documentation est mis à jour vers la version 4.2.0.

Merci beaucoup pour votre temps et vos efforts à tous.
Cela a été une sortie énorme avec beaucoup de problèmes complexes à résoudre et nous avons relevé le défi.
Super travail!

J'ai publié un article de blog. pouvons-nous fermer cela?

Oui.