Les principaux changements sont l'arrivée de nouvelles technologies telles que PolicyKit, de nouvelles améliorations de Plasma et bien sûr de nombreuses corrections de bogues (plus de 10 000).
Pourquoi les bugs corrigés durant les bétas sur les nouvelles fonctions ne devrait pas être comptabilisés?
Parce que le développement de nouvelles fonctionnalités, y compris les corrections de bugs introduits par ce développement, et la correction des bugs introduits par la correction de bugs introduits[...], est déjà inclu dans la liste des nouveautés. D'après moi.
Quand on liste ce qu'il y a de nouveau d'une version à l'autre on liste ce qui change, d'après moi :
- Il y avait un bug dans la version N, il n'est plus dans la N+1 : on a fait UNE correction. Que ça passe par 4 bug reports et 10 commits ou pas peu importe.
- Il y a une nouvelle fonctionnalité : c'est une nouvelle fonctionnalité, point barre. Peu importe le processus pour l'introduire, que ça ait causé des bugs ensuite corrigés, etc. Entre temps il y a eu des alpha, bêta, RC, peu m'importe.
Le nombre de bugs corrigés et de nouvelles fonctionnalités en général on peut le déduire du ChangeLog de version.
Si quelqu'un fait une feature request, qu'un autre introduit la fonctionnalité demandée à travers une nouvelle entrée dans le menu, qu'elle s'avère souvent utilisée et qu'on attribue une icône dans une barre d'outils ; qu'à ces deux étapes on introduit 2 bugs puis qu'on le corrige... Que finalement ça rend une ancienne fonctionnalité partiellement inutile et qu'on la simplifie...
Combien de changements on compte par rapport à la version précédente ?
Dans les stats d'activité du projet on sort le chiffre qu'on veut ! Mais dans l'annonce de la nouvelle version du logiciel... Une nouvelle fonctionnalité. Aucun bug corrigé. D'après moi.
Si pour vous « 10 000 bugs corrigés » est un nombre pertinent, pour moi aussi. Ça indique l'activité du projet. Cependant s'il correspond à ce que je comprends, je ne vois vraiment pas l'information apportée concernant la nouvelle version.
[^] # Re: Plus de 10 000... Correction de bugs ?
Posté par Pierre Carrier . En réponse à la dépêche KDE 4.3 est sorti. Évalué à 9.
Pourquoi les bugs corrigés durant les bétas sur les nouvelles fonctions ne devrait pas être comptabilisés?
Parce que le développement de nouvelles fonctionnalités, y compris les corrections de bugs introduits par ce développement, et la correction des bugs introduits par la correction de bugs introduits[...], est déjà inclu dans la liste des nouveautés. D'après moi.
Quand on liste ce qu'il y a de nouveau d'une version à l'autre on liste ce qui change, d'après moi :
- Il y avait un bug dans la version N, il n'est plus dans la N+1 : on a fait UNE correction. Que ça passe par 4 bug reports et 10 commits ou pas peu importe.
- Il y a une nouvelle fonctionnalité : c'est une nouvelle fonctionnalité, point barre. Peu importe le processus pour l'introduire, que ça ait causé des bugs ensuite corrigés, etc. Entre temps il y a eu des alpha, bêta, RC, peu m'importe.
Le nombre de bugs corrigés et de nouvelles fonctionnalités en général on peut le déduire du ChangeLog de version.
Si quelqu'un fait une feature request, qu'un autre introduit la fonctionnalité demandée à travers une nouvelle entrée dans le menu, qu'elle s'avère souvent utilisée et qu'on attribue une icône dans une barre d'outils ; qu'à ces deux étapes on introduit 2 bugs puis qu'on le corrige... Que finalement ça rend une ancienne fonctionnalité partiellement inutile et qu'on la simplifie...
Combien de changements on compte par rapport à la version précédente ?
Dans les stats d'activité du projet on sort le chiffre qu'on veut ! Mais dans l'annonce de la nouvelle version du logiciel... Une nouvelle fonctionnalité. Aucun bug corrigé. D'après moi.
Si pour vous « 10 000 bugs corrigés » est un nombre pertinent, pour moi aussi. Ça indique l'activité du projet. Cependant s'il correspond à ce que je comprends, je ne vois vraiment pas l'information apportée concernant la nouvelle version.
Merci pour votre patience.