Compatibilité rétroactive avec les anciens navigateurs

Eh bien, maintenant que nous avons la partie officielle du fil de discussion illustrée, consistant à « dénigrer Apple » et à dire qu’« ils sont les pires », je suis curieux de connaître la politique en matière de compatibilité ascendante prise en charge. La plupart des équipes de produits, sinon toutes, publient leur politique de compatibilité ascendante, et certaines sont plus généreuses que d’autres. Heureusement, la technologie progresse et, malheureusement, cela met une date d’expiration à la durée de vie utile de la plupart des technologies.

Concernant le problème soulevé par @codev, je suis également curieux car j’étais sur le point de déployer Discourse, bien que j’aie la possibilité d’avoir des utilisateurs avec des appareils vieillissants. Comme l’a suggéré @Ed_S, il se peut que ce soit quelque chose que je doive considérer, pour chercher ailleurs.

Personnellement, j’utilise une technologie qui a plus de 5 ans et j’ai de la famille avec des appareils un peu plus anciens. Je ne pense pas être le seul dans ce cas. À l’honneur d’Apple, leur matériel est solide (ce qui signifie qu’il continue généralement de bien fonctionner bien au-delà du logiciel pris en charge), et en général, ils offrent une couverture généreuse pour la compatibilité ascendante.

Les logiciels et les frameworks de sécurité évoluent constamment, et encore plus de nos jours, nécessitant des mises à niveau car tant de choses sont interdépendantes. J’accepte l’argument de la mise à niveau pour la sécurité, cependant, ne plus prendre en charge une version particulière de quelque chose parce qu’elle n’est plus « expédiée » ne signifie pas qu’il n’y a pas d’utilisateurs qui utilisent encore la technologie.

Si quelqu’un devait argumenter : « Hé, je dois prendre en charge des clients avec des navigateurs non SSL datant de 1993 », je suis d’accord que c’est absurde. Cependant, si nous disons que vous ne pouvez utiliser que quelque chose qui a été publié en tant que N-1 (disons, expédié uniquement au cours des 18 derniers mois), eh bien, tout le monde ne met pas à jour tous les 6 mois.

Firefox, par exemple, fournit des ESR (versions prises en charge étendues) pour les anciennes plateformes. C’est formidable pour Firefox et pour ceux qui ont besoin d’ESR. Cependant, cela devient sans objet si les fournisseurs, par exemple Discourse, ne prennent pas en charge quelque chose en raison d’un numéro de version de navigateur stupide ne correspondant pas à leur chaîne de version minimale prédéfinie / codée en dur. S’il existe des frameworks requis, c’est une chose – s’il s’agit simplement de « la version 1 n’est pas égale à 2 », mais sinon cela fonctionne, alors c’est vraiment malheureux. Je constate de plus en plus ce manque d’intérêt pour la prise en charge des éléments antérieurs. C’est une tendance décevante. Les ingénieurs d’aujourd’hui, nés à la fin des années 80 et tout au long des années 90, ont grandi dans une culture où « il faut toujours mettre à niveau ».

Je sais que j’ai fait des détours ici, merci pour la licence artistique. Je ne veux pas perdre de vue la requête originale de @codev. C’est important, surtout là où Discourse fournit un objectif si significatif en matière de communication et de communauté.

4 « J'aime »