1. Introduction : Apache Iceberg 1.10, L’ère de la Spécification V3
Apache Iceberg s’impose comme une pierre angulaire des architectures modernes de Data Lakehouse, comblant le fossé entre la flexibilité des lacs de données et la fiabilité des entrepôts de données. Le format de table apporte des garanties cruciales telles que les transactions ACID, le Time Travel et une gestion efficace des métadonnées, rendant les lacs de données plus fiables et performants pour l’analyse.
Historiquement, Iceberg a évolué à travers des versions de spécification, avec la version v2 qui a introduit des fonctionnalités essentielles comme les suppressions au niveau de la ligne. Cependant, la sortie de la version 1.10.0 d’Iceberg, ce 11 Septembre 2025, marque un tournant décisif. Cette version est la première implémentation stable de la spécification format-version 3 (V3). Le passage à V3 n’est pas une simple mise à jour itérative, mais une refonte stratégique visant à résoudre les derniers goulots d’étranglement de performance à grande échelle et à étendre la flexibilité du format pour des cas d’usage plus complexes et à forte volatilité.
Les ambitions de la spécification V3 sont claires : optimiser les performances pour les charges de travail dynamiques, introduire la prise en charge de types de données plus riches et avancer vers une unification des fonctionnalités clés de l’écosystème open source. Les sections suivantes détaillent les avancées les plus significatives de cette version et explorent leurs implications concrètes pour les architectes et ingénieurs de données.
2. L’Innovation Majeure : Les Vecteurs de Suppression Binaires (Binary Deletion Vectors)
Problématique des Versions Précédentes
Le modèle de gestion des suppressions et des mises à jour dans les versions antérieures d’Iceberg (V2) s’appuyait sur une approche merge-on-read. Pour éviter de réécrire des fichiers de données entiers lors d’une suppression de ligne, Iceberg créait des « fichiers de suppression positionnelle » qui contenaient des tuples de (chemin_du_fichier, position_de_la_ligne) pour indiquer les lignes à ignorer. Cette approche était efficace pour les volumes de données modérés, mais elle entraînait des défis importants pour les charges de travail à forte volatilité, comme les pipelines de capture de données modifiées (
Change Data Capture ou CDC).
Les inconvénients de ce modèle étaient triples :
- Fragmentation et Explosion des Fichiers : Chaque opération de suppression ou de mise à jour créait de nouveaux fichiers de suppression. Avec le temps, cela entraînait une explosion du nombre de petits fichiers, ce qui augmentait la complexité de gestion et la latence de lecture en raison des multiples requêtes d’E/S nécessaires pour lire à la fois les fichiers de données et tous les fichiers de suppression associés.
- Performance de Lecture : Le moteur de requête devait fusionner les informations des fichiers de suppression avec les fichiers de données en mémoire, un processus qui devenait lent à mesure que le nombre de fichiers de suppression augmentait.
- Coûts de Stockage : Le nombre croissant de petits fichiers pouvait également engendrer des coûts de stockage plus élevés sur les systèmes de fichiers objet comme S3.
Fonctionnement des Vecteurs de Suppression : Une Architecture Révolutionnée
Iceberg 1.10 (V3) résout cette problématique de manière élégante en introduisant les vecteurs de suppression binaires. L’idée centrale est de déplacer l’information de suppression directement aux côtés du fichier de données auquel elle s’applique. Chaque fichier de données est désormais associé à un petit fichier « sidecar » au format Puffin. Ce fichier sidecar contient un vecteur de suppression, qui est un bitmap compact et efficace, généralement un Roaring Bitmap.
Le processus de lecture est grandement simplifié. Le moteur de requête lit le fichier de données et son vecteur de suppression associé en une seule opération. Pendant le balayage des lignes, il vérifie le bitmap avec une surcharge minimale et ignore les lignes marquées pour suppression. Cette conception réduit considérablement les E/S et améliore les performances de lecture.
Pour illustrer ce changement, voici une représentation conceptuelle des deux approches :
Schéma Comparatif des Architectures de Suppression (V2 vs. V3)
- Modèle V2 (Fichiers de suppression positionnelle) :
- Un fichier de données (données_1.parquet) est lu.
- Pour déterminer les lignes supprimées, le moteur doit aussi lire de nombreux fichiers de suppression (suppressions_1.avro, suppressions_2.avro, etc.) stockés séparément.
- La fusion des informations de suppression et de données se fait à la lecture, entraînant une latence accrue due aux multiples accès aux métadonnées et aux fichiers.
- Modèle V3 (Vecteurs de suppression binaires) :
- Un fichier de données (données_1.parquet) est lu.
- Un petit fichier « sidecar » (données_1.puffin) contenant le vecteur de suppression binaire est attaché et lu en même temps.
- Le moteur utilise le bitmap compact pour masquer les lignes supprimées à la volée.
- Le chemin de lecture est direct et optimisé.
Ce changement d’architecture est fondamental. Il ne s’agit pas seulement d’une amélioration technique, mais d’une transformation de la façon dont les opérations de suppression sont gérées, les rendant plus performantes et plus tolérantes aux charges de travail dynamiques. Cette évolution s’inscrit dans une tendance plus large d’optimisation des formats de tables ouverts, où plusieurs projets explorent des solutions similaires pour répondre aux défis de performance à grande échelle.
Exemple de Code
Pour bénéficier des vecteurs de suppression, une table Iceberg doit être créée avec la spécification V3 (format-version=’3′) et le mode de suppression merge-on-read.
-- SQL -- Création d'une table Iceberg avec le format de version 3
CREATE OR REPLACE TABLE prod.db.my_cdc_table (
id BIGINT,
data STRING,
dt DATE
) USING iceberg
TBLPROPERTIES (
'write.delete.mode' = 'merge-on-read',
'format-version' = '3'
);Explication du Code :
- ‘write.delete.mode’ = ‘merge-on-read’ : Active le mode de suppression différée qui utilise les vecteurs de suppression
- ‘format-version’ = ‘3’ : Spécifie l’utilisation de la spécification V3 d’Iceberg
- Cette configuration est essentielle car les vecteurs de suppression ne sont disponibles qu’en mode merge-on-read avec la version V3
Une fois la table créée, toute opération de suppression ou de mise à jour (via DELETE ou MERGE INTO) générera automatiquement les vecteurs de suppression binaires sans nécessiter de logique supplémentaire de la part de l’utilisateur.
Bénéfices Métiers
L’implémentation des vecteurs de suppression binaires se traduit par des avantages métier directs :
- Performance et Coût : Amélioration significative des performances d’écriture et de suppression sur les tables à forte volatilité. La réduction du nombre de fichiers se traduit par des coûts de stockage moindres et des opérations plus rapides.
- Pipelines CDC Plus Efficaces : Cette fonctionnalité rend les pipelines de CDC et les opérations de mise à jour en temps quasi réel beaucoup plus efficaces et fiables. Le modèle de « suppression différée » (lazy deletion) permet de privilégier la performance d’écriture, ce qui est pertinent pour les cas d’usage où l’ingestion de données est primordiale.
- Simplification Opérationnelle : La logique de compaction devient plus simple et plus efficace, car le moteur de requête n’a plus à gérer une multitude de petits fichiers de suppression éparpillés.
3. Le Lignage de Ligne (Row-Level Lineage) : Confiance et Gouvernance des Données
Problématique
Les versions précédentes d’Iceberg offraient une fonctionnalité de Time Travel très puissante, permettant de revenir à n’importe quel état de la table via un instantané (snapshot). Cependant, il était difficile de suivre l’historique d’une ligne de données individuelle à travers les différents instantanés. Les questions comme « Quand cet enregistrement a-t-il été mis à jour pour la dernière fois? » ou « Quel commit a introduit cette ligne? » restaient complexes à répondre, rendant l’audit et le débogage fastidieux.
Fonctionnement : L’Identification au Cœur du Changement
La spécification Iceberg V3 résout ce problème en introduisant la traçabilité (lignage) à la ligne. Elle ajoute deux métadonnées cruciales pour chaque ligne : un identifiant de ligne stable (_row_id) et le numéro de séquence (sequence_number) de la dernière modification.
L’identifiant de ligne _row_id est un identifiant unique et stable qui permet de suivre un enregistrement spécifique à travers les différentes versions de la table. Le numéro de séquence, quant à lui, est incrémenté à chaque nouveau commit, agissant comme un horodatage logique qui indique quand une ligne a été créée ou modifiée pour la dernière fois.
Le mécanisme d’affectation de _row_id est particulièrement ingénieux. Il n’est pas assigné directement à l’écriture, mais de manière différée lors du commit du snapshot. Le _row_id d’une ligne est calculé en combinant le first_row_id du fichier manifeste dans lequel la ligne est stockée et la position (_pos) de la ligne dans ce fichier. Cette méthode garantit une cohérence forte même en présence de commits concurrents.
Schéma Illustratif
Pour visualiser le concept, imaginez le cycle de vie d’une ligne de données :
- Instant 1 : Insertion. Une nouvelle ligne est ajoutée (par exemple, un client id=123). Elle est associée à un _row_id stable et un numéro de séquence sequence_number=1.
- Instant 2 : Mise à Jour. Les données du client id=123 sont mises à jour. Au lieu de réécrire le fichier de données, une nouvelle entrée est ajoutée dans un nouveau fichier de données (avec un vecteur de suppression qui marque l’ancienne ligne comme supprimée), et le numéro de séquence du nouveau fichier passe à sequence_number=2.
- Instant 3 : Audit. Un ingénieur de données peut interroger la table en utilisant le _row_id pour retracer toute l’histoire de la ligne, voyant sa valeur et son numéro de séquence à chaque instantané.
Ce mécanisme élève Iceberg du statut de simple format de table à celui de plateforme de gouvernance de données. En intégrant la traçabilité au niveau de la ligne, la communauté Iceberg répond à une exigence métier fondamentale pour garantir la confiance dans les données et faciliter la conformité réglementaire.
Bénéfices Métiers
- Gouvernance et Conformité : Le lignage de ligne fournit un « audit trail » clair et granulaire, essentiel pour se conformer aux réglementations de plus en plus strictes en matière de données (ex. RGPD).
- Fiabilité des Pipelines : Il permet la construction de pipelines de CDC plus fiables et précis. Le suivi des modifications à la ligne permet de ne traiter que les données pertinentes pour les systèmes en aval.
- Débogage Simplifié : En cas d’anomalie de données, le lignage permet de répondre rapidement à des questions critiques pour le débogage, comme « Quand et comment cette ligne a-t-elle été modifiée? ».
4. Évolution du Schéma Simplifiée et Valeurs par Défaut
Problématique
L’ajout d’une nouvelle colonne à une table existante est une opération courante dans l’ingénierie des données. Cependant, l’ajout d’une colonne avec une contrainte NON-NULL posait un défi majeur : les lignes existantes n’avaient pas de valeur pour cette nouvelle colonne. Pour respecter la contrainte, il fallait soit accepter des valeurs NULL, soit effectuer un « backfill » manuel de toutes les données historiques, une opération coûteuse et chronophage qui nécessitait la réécriture de l’ensemble des fichiers de données.4 Cette opération était source de « downtime » et de lourde planification.
Fonctionnement : Une Opération Instantanée
Iceberg V3 résout ce problème de manière élégante en permettant de définir une valeur par défaut directement dans les métadonnées de la table. Lorsqu’une nouvelle colonne est ajoutée, la valeur par défaut est spécifiée dans l’opération DDL (Data Definition Language).
L’opération ALTER TABLE est instantanée, car elle ne touche à aucun fichier de données. Les moteurs de requête appliquent la valeur par défaut pour les lignes historiques à la volée, sans réécriture.
Exemple de Code
La syntaxe SQL pour cette opération est simple et intuitive :
-- SQL
ALTER TABLE events ADD COLUMN event_version INT DEFAULT 1;Après l’exécution de cette commande, les nouvelles lignes insérées auront une valeur par défaut de 1 pour event_version, tandis que les lignes historiques seront lues comme si elles avaient également cette valeur.
Bénéfices Métiers
- Agilité et Productivité : Les équipes de données peuvent faire évoluer leurs schémas à la vitesse des besoins métier, sans interruption ni lourde planification des opérations de maintenance. Les cycles de développement sont accélérés et la flexibilité accrue.
- Simplicité : L’ingénieur de données n’a plus besoin de gérer une logique de remplissage complexe côté client ou de planifier des jobs de backfill massifs. Cela simplifie considérablement les opérations de maintenance.
5. Nouveaux Types de Données : La Fin des Silos pour les Données Complexes
Problématique
Le support limité pour les données semi-structurées et géospatiales dans les formats de lacs de données traditionnels forçait les entreprises à utiliser des systèmes spécialisés en silo ou à effectuer des processus d’extraction, de transformation et de chargement (ETL) coûteux pour aplatir les données. Cela créait une fragmentation de l’architecture de données et entravait la capacité d’une entreprise à interroger et analyser l’ensemble de ses données dans un seul écosystème.
Fonctionnalités et Cas d’Usage
Iceberg 1.10 (V3) enrichit considérablement son système de types, faisant un pas de plus vers son rôle de format universel capable de gérer tous les types de données directement dans le lac de données.
Type VARIANT pour les Données Semi-Structurées
Le nouveau type VARIANT permet de stocker des données semi-structurées comme des documents JSON ou des structures imbriquées dans une seule colonne, sans schéma prédéfini et sans perte d’efficacité de stockage.
Exemple de Code :
Pour créer une table avec une colonne VARIANT :
-- SQL
CREATE TABLE IF NOT EXISTS dev.default.users (
id BIGINT,
properties VARIANT
) USING iceberg
TBLPROPERTIES (
'format-version' = '3'
);Pour insérer et interroger des données semi-structurées, il faut utiliser des fonctions spécifiques, comme parse_json() et variant_get().
-- SQL
-- Insertion de données JSON dans une colonne VARIANT
INSERT INTO dev.default.users (id, properties) VALUES
(1, parse_json('{"name":"Alice", "address": {"city":"NYC"}}')),
(2, parse_json('{"name":"Bob", "address": {"city":"LA"}}'));
-- Interrogation des champs imbriqués
SELECT
id,
variant_get(properties, '$.name', 'string') AS user_name,
variant_get(properties, '$.address.city', 'string') AS user_city
FROM dev.default.users;Explication du Code :
- parse_json() : Convertit une chaîne JSON en type VARIANT
- variant_get() : Extrait une valeur spécifique du VARIANT en utilisant la notation JSONPath ($.nom_champ)
- Le troisième paramètre (‘string’) spécifie le type de retour attendu
- Cette approche permet de stocker des structures JSON complexes sans définir un schéma rigide
Bénéfices Métiers : Ce type est idéal pour l’ingestion et l’analyse directe de logs d’événements, de données IoT, de réponses d’API ou de profils utilisateur dynamiques. Il élimine le besoin de processus ETL complexes pour traiter ces données, permettant de les intégrer et de les analyser directement dans l’écosystème du Data Lakehouse.
Types Géospatiaux (geometry, geography)
La spécification V3 ajoute un support natif pour les types de données géospatiaux, comblant un écart de longue date avec les bases de données spatiales traditionnelles.5
Exemple de Code :
-- SQL
CREATE TABLE local.db.icetable (
id STRING,
point_geom GEOMETRY
) USING iceberg
TBLPROPERTIES('format-version'='3');Explication du Code :
- GEOMETRY : Type de données pour les objets spatiaux planaires (points, lignes, polygones)
- Les données sont stockées au format Well-Known Binary (WKB) pour l’interopérabilité
- Le système de coordonnées par défaut est OGC:CRS84 (longitude-latitude basé sur WGS84)
Bénéfices Métiers : L’intégration native des types géospatiaux permet aux organisations d’appliquer les fonctionnalités d’Iceberg – telles que les transactions ACID, les opérations DML fiables et le Time Travel – à des jeux de données géospatiaux à grande échelle. Cela brise les silos de données et ouvre la voie à des analyses spatiales complexes directement sur le lac de données, sans avoir à migrer les données vers des systèmes spécialisés.
Timestamps en Précision Nanoseconde
Pour les applications qui exigent une précision temporelle extrême, V3 introduit la prise en charge des timestamp_ns et timestamptz_ns. Cette amélioration est essentielle pour des cas d’usage comme l’analyse de séries temporelles, les données de capteurs IoT ou les applications financières où la résolution au-delà de la microseconde est critique pour la pertinence de l’analyse.
6. Considérations de Migration et Défis Opérationnels
Migration V2 vers V3 : Points d’Attention
Bien que la spécification V3 apporte des avancées significatives, la migration depuis V2 nécessite une planification minutieuse :
- Compatibilité Descendante : Les moteurs de requête doivent être mis à jour pour supporter pleinement V3. Tous les moteurs ne supportent pas encore toutes les fonctionnalités V3, ce qui peut créer des incompatibilités temporaires dans des environnements hétérogènes.
- Migration Progressive : La migration des tables existantes vers V3 peut nécessiter une approche progressive. Les nouvelles fonctionnalités comme les vecteurs de suppression ne s’appliquent qu’aux nouvelles opérations, les données historiques conservant leur format V2.
- Impact sur les Performances : Bien que V3 améliore les performances à long terme, la période de transition peut temporairement impacter les performances en raison de la coexistence des formats et de la nécessité de maintenir la compatibilité.
- Formation des Équipes : Les nouvelles fonctionnalités comme le lignage de ligne et les types VARIANT nécessitent une montée en compétences des équipes de données pour être exploitées efficacement.
Limitations Actuelles
- Adoption Écosystémique : Tous les moteurs de calcul ne supportent pas encore l’intégralité des fonctionnalités V3, particulièrement les nouveaux types de données.
- Maturité des Outils : Les outils de monitoring et d’administration doivent être adaptés pour gérer les nouvelles métadonnées introduites par V3.
- Complexité Accrue : L’enrichissement du modèle de métadonnées augmente la complexité opérationnelle, nécessitant une expertise approfondie pour l’optimisation.
7. Améliorations Écosystémiques et Correctifs de Stabilité
Outre les innovations majeures de la spécification V3, la version 1.10 d’Iceberg apporte des améliorations cruciales pour la stabilité, la performance et l’intégration avec l’écosystème de la donnée.
- Support pour les Moteurs de Calcul : Iceberg 1.10 offre un support immédiat pour les dernières versions des moteurs de traitement, notamment Apache Flink 2.0 et Apache Spark 4.0. Ce support garantit que les utilisateurs d’Iceberg peuvent rester à la pointe de la technologie sans craindre des problèmes de compatibilité, renforçant la position d’Iceberg comme un composant central de l’architecture.
- Opérabilité et Performance : La version 1.10 introduit le calcul incrémental des statistiques de partition pour Spark, ce qui réutilise les fichiers de statistiques existants pour économiser temps et ressources. De plus, le code de compaction pour Flink et Spark a été refactorisé pour partager la même logique, et un nouveau paramètre
max-files-to-rewrite donne un meilleur contrôle sur les tâches de compaction. - Fiabilité et Flexibilité : Plusieurs correctifs critiques ont été apportés, notamment la correction d’un bogue de « stalling » pour Spark Structured Streaming et un correctif pour la gestion des erreurs serveur 5xx dans le client REST. Une nouvelle alerte
ignoreMissingFiles a été ajouté pour améliorer le processus d’importation de tables et éviter les échecs de migration en cas de fichiers manquants. Enfin, l’ajout d’un plugin de catalogue pour
BigQuery Metastore augmente la flexibilité et l’intégration avec l’écosystème Google Cloud. Ces améliorations illustrent la maturité du projet et son engagement envers la fiabilité en production.
7. Conclusion et Perspectives Stratégiques
La version 1.10 d’Apache Iceberg, en implémentant la spécification format-version 3, représente un bond en avant dans le développement des Data Lakehouses. Les avancées ne sont pas de simples ajouts de fonctionnalités, mais des solutions de fond aux défis opérationnels et analytiques qui persistaient.
Le tableau suivant synthétise les innovations majeures et leurs bénéfices métier associés :
| Fonctionnalité V3 | Bénéfice Technique Clé | Bénéfice Métier | Cas d’Usage Principal |
|---|---|---|---|
| Vecteurs de Suppression Binaires | Réduction des E/S, moins de fichiers | Pipelines CDC plus rapides, coûts de stockage réduits | Correction de données, mises à jour fréquentes |
| Lignage de Ligne | Suivi historique des lignes | Gouvernance, audit, débogage simplifié | Conformité réglementaire, pipelines de CDC fiables |
| Valeurs par Défaut | Évolution du schéma instantanée | Agilité des développeurs, zéro « downtime » | Ajout de colonnes non-nullable à des tables massives |
| Types Avancés (VARIANT, Géospatial) | Support natif pour données complexes | Fin des silos de données, analyse plus riche | Logs d’événements, IoT, analyse cartographique |
Ces fonctionnalités collectives transforment Iceberg en un format capable de gérer des charges de travail qui étaient auparavant l’apanage des entrepôts de données et des bases de données spécialisées. Le lac de données n’est plus un simple « dépôt » de fichiers, mais une plateforme d’analyse et de traitement de données fiable et performante.1
L’implémentation des vecteurs de suppression, du lignage de ligne et des types de données avancés montre que le projet Iceberg ne cesse d’innover en répondant à des problématiques métier concrètes. Cette évolution s’accompagne d’une maturation progressive de l’écosystème des formats de tables ouverts, où les différents projets développent des solutions complémentaires aux défis communs de l’analytique à grande échelle. Pour les entreprises, cette dynamique réduit les risques de verrouillage technologique (vendor lock-in) et ouvre la voie à des architectures de données plus flexibles et évolutives. Le futur de l’architecture des données se dessine autour de formats ouverts et capables de relever les défis de performance, de flexibilité et de gouvernance à grande échelle.
Liens
- What is Apache Iceberg? Benefits and use cases | Google Cloud, consulté le septembre 15, 2025, https://cloud.google.com/discover/what-is-apache-iceberg
- Apache Iceberg Tutorial: The Ultimate Guide for Beginners | Estuary, consulté le septembre 15, 2025, https://estuary.dev/blog/apache-iceberg-tutorial-guide/
- What’s New in Apache Iceberg 1.10.0, and what comes next! | Dremio, consulté le septembre 15, 2025, https://www.dremio.com/blog/whats-new-in-apache-iceberg-1-10-0-and-what-comes-next/
- What’s new in Apache Iceberg v3? – Google Open Source Blog, consulté le septembre 15, 2025, https://opensource.googleblog.com/2025/08/whats-new-in-iceberg-v3.html
- What’s New in Apache Iceberg Format Version 3? – Dremio, consulté le septembre 15, 2025, https://www.dremio.com/blog/apache-iceberg-v3/
- Apache Iceberg™ v3: Moving the Ecosystem Towards Unification | Databricks Blog, consulté le septembre 15, 2025, https://www.databricks.com/blog/apache-icebergtm-v3-moving-ecosystem-towards-unification
- Comparison of Delete Strategies in Apache Iceberg and Delta Lake: Equality, Position, and Performance | OLake, consulté le septembre 15, 2025, https://olake.io/blog/iceberg-delta-lake-delete-methods-comparison
- Creating Delete Vectors using Java API or Spark · Issue #11968 · apache/iceberg – GitHub, consulté le septembre 15, 2025, https://github.com/apache/iceberg/issues/11968
- Iceberg v3 + Starburst, consulté le septembre 15, 2025, https://www.starburst.io/blog/iceberg-v3/
- metadata – PyIceberg, consulté le septembre 15, 2025, https://py.iceberg.apache.org/reference/pyiceberg/table/metadata/
- Row Lineage in Apache Iceberg – Medium, consulté le septembre 15, 2025, https://medium.com/@kaushikranjan/row-lineage-in-apache-iceberg-7f2412ea27c0
- Apache Iceberg and Parquet now support GEO – Wherobots, consulté le septembre 15, 2025, https://wherobots.com/blog/apache-iceberg-and-parquet-now-support-geo/
- Learn how to use Variant Feature in Iceberg 1.10.0 V3 with PySpark Code Example | by Soumil Shah | Sep, 2025 | Medium, consulté le septembre 15, 2025, https://medium.com/@shahsoumil519/learn-how-to-use-variant-feature-in-iceberg-1-10-0-v3-with-pyspark-code-example-2c2ae84829cf
- Deep Dive: Joining Apache Iceberg Tables on VARIANT Columns with Spark SQL – Medium, consulté le septembre 15, 2025, https://medium.com/@shahsoumil519/deep-dive-joining-apache-iceberg-tables-on-variant-columns-with-spark-sql-5c6eca8841de
- Benefits of Apache Iceberg for geospatial data analysis – Wherobots, consulté le septembre 15, 2025, https://wherobots.com/blog/benefits-of-apache-iceberg-for-geospatial-data-analysis/
- Apache Iceberg™ 1.10: New Features, Fixes & What’s Next for Data Lakes, consulté le septembre 15, 2025, https://www.snowflake.com/en/engineering-blog/apache-iceberg-1-10-new-features-fixes/
