eh plutôt que de gérer des bugs dans la version à venir pour des nouvelles fonctionnalités, ils préfèrent sélectionner les fonctionnalités un peu plus abouties pour avoir une version cohérente. Seems legit. !?
Un avantage : pour la version 20 suivante, ça fait un lot de fonctionnalités identifiées à retravailler et finaliser ;-) Si elles étaient attendues, bah il y aura du monde pour y contribuer, sinon c'est qu'elles n'étaient pas si urgentes :p
Un autre avantage : cela permet de se concentrer sur les fonctionnalités abouties et attendues pour sortir une version 19 stable. J'ose espérer qu'ils ont choisi un périmètre cohérent.
Visiblement, le déluge de vulnérabilités (vulnpocalypse) remontées depuis le printemps a sollicité un peu trop les développeurs, les détournant des travaux en cours sur de nouvelles fonctionnalités :/
Bon il ne donne pas trop de détails, je n'ai pas un suivi suffisamment rapproché de PostgreSQL, quelqu'un aurait plus d'infos sur les fonctionnalités ayant été validées et celles à revoir ? En quoi cela ajouterait un délai sur la prise en compte de SQL2023 par exemple ?
En tout cas, je ne vois rien que de très normal dans un cycle de développement avant la version candidate : tu sélectionnes un périmètre homogène et abouti dont tu vas devoir assurer le bon fonctionnement ; si ce n'est pas le cas, autant mieux vaut s'éviter de la frustration de part et d'autre (ou sinon tu décales la sortie et la disponibilité des autres fonctionnalités stabilisées attendues, ce qui n'est pas le choix de PostgreSQL).
Pourquoi parler de « freiner devant la ligne d'arrivée » ? Pour moi, au contraire, tu te débarrasses de ce qui serait un fardeau pour la suite, t'es plus léger pour passer la ligne et reprendre une activité normale ;-)
# bon choix
Posté par BAud (site web personnel) . Évalué à 7 (+5/-0).
eh plutôt que de gérer des bugs dans la version à venir pour des nouvelles fonctionnalités, ils préfèrent sélectionner les fonctionnalités un peu plus abouties pour avoir une version cohérente. Seems legit. !?
Un avantage : pour la version 20 suivante, ça fait un lot de fonctionnalités identifiées à retravailler et finaliser ;-) Si elles étaient attendues, bah il y aura du monde pour y contribuer, sinon c'est qu'elles n'étaient pas si urgentes :p
Un autre avantage : cela permet de se concentrer sur les fonctionnalités abouties et attendues pour sortir une version 19 stable. J'ose espérer qu'ils ont choisi un périmètre cohérent.
Visiblement, le déluge de vulnérabilités (vulnpocalypse) remontées depuis le printemps a sollicité un peu trop les développeurs, les détournant des travaux en cours sur de nouvelles fonctionnalités :/
Bon il ne donne pas trop de détails, je n'ai pas un suivi suffisamment rapproché de PostgreSQL, quelqu'un aurait plus d'infos sur les fonctionnalités ayant été validées et celles à revoir ? En quoi cela ajouterait un délai sur la prise en compte de SQL2023 par exemple ?
En tout cas, je ne vois rien que de très normal dans un cycle de développement avant la version candidate : tu sélectionnes un périmètre homogène et abouti dont tu vas devoir assurer le bon fonctionnement ; si ce n'est pas le cas, autant mieux vaut s'éviter de la frustration de part et d'autre (ou sinon tu décales la sortie et la disponibilité des autres fonctionnalités stabilisées attendues, ce qui n'est pas le choix de PostgreSQL).
Pourquoi parler de « freiner devant la ligne d'arrivée » ? Pour moi, au contraire, tu te débarrasses de ce qui serait un fardeau pour la suite, t'es plus léger pour passer la ligne et reprendre une activité normale ;-)
[^] # Re: bon choix
Posté par wilk (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Rien de péjoratif de ma part et très sage initiative au contraire !
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.