La libération de la version 1 Go, 1 Go pour faire court, est une étape majeure dans le développement de la langue. (go)

introduction

La libération de la version 1 Go, 1 Go pour faire court, est une étape majeure dans le développement de la langue. Go 1 est une plate-forme stable pour la croissance des programmes et des projets écrits en Go.

Aller 1 définit deux choses: d'abord, la spécification de la langue; et la seconde, la spécification d'un ensemble d'API de base, les «packages standard" de la bibliothèque Go. Le Go 1 version inclut leur mise en œuvre sous la forme de deux suites de compilation (gc et gccgo), et le noyau bibliothèques elles-mêmes.

Il est prévu que les programmes écrits à la spécification 1 Go vont continuer à compiler et fonctionner correctement, inchangée, au cours de la durée de vie de cette spécification. À un certain moment indéterminée, une spécification Go 2 peut se poser, mais jusqu'à ce moment, Aller programmes qui fonctionnent aujourd'hui devraient continuer à travailler même comme futur «point» rejets de 1 Go se posent (1.1 Go, Go 1.2, etc.).

La compatibilité est au niveau de la source. La compatibilité binaire pour les paquets compilés ne sont pas garanties entre les versions. Après un point de déverrouillage, la source Go devra être recompilés pour être liés à la nouvelle version.

Les API peuvent grandir, acquérir de nouveaux forfaits et fonctions, mais pas d'une manière qui rompt Go Code 1 existant.

Attentes

Bien que nous nous attendons à ce que la grande majorité des programmes sera de maintenir cette compatibilité avec le temps, il est impossible de garantir que aucun changement futur va briser tout programme. Ce document est une tentative pour définir les attentes pour la compatibilité des logiciels Go 1 à l'avenir. Il ya un certain nombre de façons dont un programme qui compile et fonctionne aujourd'hui peut ne pas le faire après une future version de point. Ils sont tous les enregistrements peu probable, mais vaut la peine.

Sécurité. Un problème de sécurité dans la spécification ou de la mise en œuvre peut venir à la lumière dont la résolution nécessite la compatibilité de rupture. Nous nous réservons le droit de répondre à ces questions de sécurité.
Comportement non spécifié. La spécification Go essaie d'être explicite sur la plupart des propriétés de la langue, mais il ya certains aspects qui ne sont pas définies. Programmes qui dépendent de tels comportement non spécifié peuvent se briser dans les futures versions.
Les erreurs de spécification. Si il devient nécessaire de corriger une incohérence ou incomplets dans la spécification, la résolution du problème pourrait affecter le sens ou la légalité des programmes existants. Nous nous réservons le droit de répondre à ces questions, y compris la mise à jour des implémentations. Sauf pour les questions de sécurité, pas de changements incompatibles à la spécification seraient faites.
Bugs. Si un compilateur ou de la bibliothèque a un bug qui viole la spécification, un programme qui dépend du comportement buggy peut se briser si le bug est corrigé. Nous nous réservons le droit de fixer ces bugs.
Littéraux structure. Pour l'ajout de fonctionnalités dans les versions ultérieures de points, il peut être nécessaire d'ajouter des champs à structs exportés dans l'API. Code qui utilise littéraux struct sans clé (comme pkg.T {3, "x"}) pour créer des valeurs de ces types ne parviendrait pas à compiler, après un tel changement. Toutefois, le code qui utilise littéraux à clé (pkg.T {A: 3, B: "x"}) continuera à compiler, après un tel changement. Nous mettrons à jour ces structures de données d'une manière qui permet littéraux struct à clé pour rester compatible, bien que non détrompé littéraux peuvent échouer à compiler. (Il ya aussi des cas plus complexes impliquant des structures de données imbriquées ou des interfaces, mais ils ont la même résolution.) Nous recommandons donc que les littéraux composites dont le type est défini dans un paquet séparé devraient utiliser la notation à clé.
Méthodes. Comme avec les champs struct, il peut être nécessaire d'ajouter des méthodes de types. Dans certaines circonstances, comme lorsque le type est intégré dans une structure avec un autre type, l'ajout de la nouvelle méthode peut briser la structure en créant un conflit avec une méthode existante de l'autre type intégré. Nous ne pouvons pas protéger contre ce cas rare et ne pas garantir la compatibilité devrait-il se poser.
Les importations point. Si un programme importe un package standard en utilisant l'importation. «chemin», noms supplémentaires définies dans le package importé dans les futures versions peuvent entrer en conflit avec d'autres noms définis dans le programme. Nous ne recommandons pas l'utilisation de l'importation. Extérieur de tests, et de l'utiliser peut provoquer un programme à ne pas compiler dans les futures versions.
Utilisation du paquet dangereux. Forfaits qui importent dangereuse peut dépendre de propriétés internes de la mise en œuvre Go. Nous nous réservons le droit d'apporter des modifications à la mise en œuvre qui peuvent briser ces programmes.
Bien sûr, pour toutes ces possibilités, si elles se produisent, nous nous efforcerons de mettre à jour chaque fois que possible les spécifications, des compilateurs, ou des bibliothèques sans affecter le code existant.

Ces mêmes considérations valent pour rejets ponctuels successifs. Par exemple, le code qui fonctionne sous 1.2 Go devrait être compatible avec Go 1.2.1, 1.3 Go, Go 1.4, etc., mais pas nécessairement avec Go 1.1, car il peut utiliser des fonctionnalités ajoutées que dans Go 1.2

Fonctionnalités ajoutées entre les versions, disponibles dans le référentiel source, mais ne font pas partie des versions binaires numérotés, sont en cours de développement. Aucune promesse de compatibilité est faite pour les logiciels utilisant ces fonctions jusqu'à ce qu'ils aient été libérés.

Enfin, bien que ce soit pas un problème exactitude, il est possible que la performance d'un programme peut être affecté par des changements dans la mise en œuvre des compilateurs ou des bibliothèques dont il dépend. Aucune garantie ne peut être faite à propos de la performance d'un programme donné entre deux versions.

Bien que ces attentes appliquent à 1 Go lui-même, nous espérons que des considérations similaires seraient prises pour le développement de logiciels développés en externe sur la base de 1 Go.

Sous-dépôts

Code en sous-dépositaires de la principale aller arbre, comme golang.org/x/net, peut être développé dans le cadre des exigences de compatibilité plus souples. Cependant, les sous-répertoires seront étiquetés comme appropriée pour identifier les versions qui sont compatibles avec les Go 1 rejets ponctuels.

Systèmes d'exploitation

Il est impossible de garantir la compatibilité à long terme avec des interfaces de système d'exploitation, qui sont modifiés par des tiers. Le syscall package est donc hors du champ des garanties faites ici. Comme de Go version 1.4, le syscall paquet est gelé. Toute évolution de l'interface de l'appel système doit être soutenu ailleurs, comme dans le go.sys subrepository. Pour plus de détails et de fond, voir ce document.

Outils

Enfin, la chaîne d'outils Go (compilateurs, des linkers, de construire des outils, etc.) sont en cours de développement et peut changer de comportement. Cela signifie, par exemple, que les scripts qui dépendent de l'emplacement et les propriétés des outils peuvent être brisés par un point de déverrouillage.

Ces mises en garde de côté, nous croyons que 1 Go sera une base solide pour le développement de Go et de son écosystème.