@sebsauvage

Oui, aussi.

Mais en même temps, les OS évoluent… faut quand même de temps à autre une maj pour les dépendances.

@sebsauvage le développement logiciel aujourd'hui, c’est de l’ajout de fonctionnalités inutiles jusqu’à atteindre le seuil de merdification.

@sebsauvage pour nuancer je dirais que le principal soucis aujourd'hui c'est déjà de commencer avec des produits finis plutôt que terminés. Finis dans le sens de délivrable sans problème majeur. C'est de plus en plus commun et "normal" de se retrouver avec un programme non finis, version alpha ou beta, délivré mais pas entièrement fonctionnel et necessitant de futures updates.

@sebsauvage peut pas de côté, j’y pensais ce matin à propos de 7zip. La faille détectée l’an dernier a été documentée. 7zip est maintenu à jour branché 25.x), p7zip a priori non (16.x), bien qu’il fonctionne tres bien.

P7zip n’a *a priori* pas besoin de maj pour être utile et fiable, voire considéré comme terminé. Mais s’il est impacté par la faille, que faire ?

Je rejoins d’autres commentaires : l’idée qu’un soft soit fini me plaît, mais c’est différent d’un soft abandonné. Qu’on peut formuler comme la différence entre l’évolution et la maintenance.

@sebsauvage le problème se pose dès qu'un projet utilise des dépendances, et dès qu'il doit être packagé. Tôt ou tard, un truc pète et il faut appliquer des mises à jour.

Mais je suis d'accord sur le fond, à savoir que les fonctionnalités d'un logiciel puisse être finies, sans besoin d'en ajouter en permanence (le concept de nouvelles fonctionnalités, c'est à cause des entreprises qui embauchent une équipe de développement qu'elles doivent continuer à payer tous les mois)

@sebsauvage

#include <stdio.h>

void main()
{
printf("Hello world\n");
}

Fini, pas besoin de révision

@sebsauvage Tu n'utilise pas le fork de Shaarli ? Tu as un avis sur les changements et mises à jour ?

@sebsauvage Quand on y pense, ça s'appliquait à la plupart des softs et jeux vidéos pré-internet, en particulier sur console. Une fois la cartouche produite, c'est immuable. Il y a bien des révisons, mais le produit était essentiellement fini. Aujourd'hui, on bâcle souvent les releases parce que c'est trop simple de corriger par après, et c'est économiquement plus rentable.

@sebsauvage Ça me fait penser au "Kelvin Versioning" : l'idée c'est de partir d'une température en Kelvin, et de descendre d'un à chaque version. Une fois arrivé à 0, le logiciel n'évoluera plus jamais
https://jtobin.io/kelvin-versioning

@sebsauvage
Voilà et accepter que nous le sutilisateurs soyons satisfait de son fonctionnement et de ses services. Pas besoin de rajouter du bling-bling que l'on ne demande pas (juste pour montrer qu'en tant que dev ils peuvent... mouarf !)
🤗 🖖🏼

@sebsauvage C'est 100% la nature de ce que je disais à un ex-collègue la semaine dernière.

Il était une fois, les dev voyaient le "feature-complete" comme un St Graal. Aujourd'hui, c'est un gros-mot.

Pistes de réflexion :
- Course aux features, parallèle avec l'industrie de la consommation, toujours plus, vite fait, pas cher, obsolescence prog.
- Dogme du budget pour le neuf-qui-rapporte-marketé VS rien pour l'entretien-ou-maintenance-de-l-existant : cf. la fameuse "dette technique"

@sebsauvage

👍

@sebsauvage

Ce qui fait peur, c'est un projet avec 0 update depuis 1 an, 50 Pr de bugfix et 200 issues non trié 🥲

Mais un projet pas update, sans bug fix, et dont les seuls issue sont des demandes de feature en discussion ou refusé, ça me pose pas de soucis

@sebsauvage

Ce qui fait peur, c'est un projet avec 0 update depuis 1 an, 50 Pr de bugfix et 200 issues non trié 🥲

Mais un