Discussion :

[Stan Adkens]

Bitbucket abandonne le support Mercurial et se concentre sur Git
Les fonctionnalités et dépôts seront officiellement supprimés le 1er juin 2020

Le mouvement DevOps vient briser depuis quelques années le cycle de développement traditionnel des applications. Cette nouvelle approche est de plus en plus adoptée par les entreprises. Le DevOps offre une meilleure cohésion et communication entre les développeurs (Dev) et les chargés d’opération (Ops), permettant ainsi d’accélérer la livraison des applications et rendre celles-ci plus robustes en détectant les anomalies plus tôt. Et l’équipe de Bitbucket compte améliorer continuellement son un service web d'hébergement et de gestion de développement logiciel pour l’adapter à la manière de travailler de ses clients.

Le marché des logiciels de contrôle de version a beaucoup évolué depuis le lancement de Bitbucket en 2008. Lorsque Bitbucket a été lancé il y a plus de 10 ans, c'était un endroit où les clients hébergeaient leur code, mais au fil des ans, il est passé à une autre étape, devenant un centre de collaboration entre les développeurs et les chargés d’opération, permettant de construire, tester et déployer de nouvelles fonctionnalités plus rapidement qu’auparavant.

Avec Git devenant le système de gestion de versions par défaut au fil des années, aidant les équipes de toutes tailles à travailler plus rapidement à mesure qu'elles se repartissent, l’équipe Bitbucket, qui revendique maintenant plus de 10 millions d'utilisateurs enregistrés sur sa plateforme, réfléchit à la meilleure manière de servir ses utilisateurs à l’avenir, d’après un billet de blog publié le mardi. « …nous en sommes à un point de notre croissance où nous procédons à une évaluation plus approfondie du marché et de la meilleure façon de soutenir nos utilisateurs pour l'avenir », peut-on lire dans le billet de blog.

Et la solution de l’équipe consiste à de supprimer le support Mercurial de Bitbucket Cloud et de son API. Les fonctionnalités et dépôts Mercurial seront officiellement supprimés de Bitbucket et de son API le 1er juin 2020.

Avec plus de 28 millions de dépôts d'archives, Bitbucket a célébré ses 10 millions d'utilisateurs enregistrés dans Bitbucket Cloud en avril dernier. Bitbucket offre les intégrations avec les outils comme Jira, Trello, et le reste des outils de la famille Atlassian, propriétaire de la plateforme. La plateforme permet de déployer, tester, surveiller, analyser du code ou encore stocker des objets. Elle fournit des intégrations ouvertes avec AWS, JFrog, Datadog, LaunchDarkly, Slack et bien d'autres.

L'échéancier de suppression du support Mercurial

L’équipe Bitbucket prévoit mettre fin à la création de nouveaux dépôts Mercurial par les utilisateurs à partir du 1er février 2020. Ensuite, dès le 1er juin de la même année, les utilisateurs ne pourront pas utiliser les fonctionnalités Mercurial dans Bitbucket ou via son API et tous les dépôts Mercurial seront supprimés. Quant à l’ensemble des fonctionnalités Mercurial actuelles de Bitbucket, elles seront disponibles jusqu'au 31 mai de l’année prochaine, avant d’être supprimées.

Les raisons de l’abandon du support Mercurial au profit du Git

Bien que Bitbucket veut garder une place spéciale pour le Mercurial dans son histoire, l’équipe a décidé de se concentrer sur le Git. En effet, l'adoption de DevOps est montée en flèche au cours de la dernière décennie et les clients de la plateforme adoptent cette nouvelle façon de travailler à un rythme exponentiel, d’après le billet de blog. Avec cette évolution, Bitbucket aussi est passé du statut d'outil de gestion de contrôle de version à celui d’une plateforme de gestion du cycle de vie complet du développement de logiciel. Mais l’équipe ne compte pas s’arrêter là.

Selon l’équipe Bitbucket, la construction d'éléments de qualité exige une attention intense, alors que la prise en charge de deux systèmes de contrôle de version permet de diviser cette attention, doublant ainsi le temps d'expédition et les frais techniques. « Git étant l'outil le plus utilisé, Mercurial court le risque de négliger des problèmes à mesure que nous évoluons », peut-on lire dans le billet de blog.

Pour justifier sa décision d’abandon du support Merccurial, l’équipe Bitbucket rapport les résultats d’une enquête « Stack Overflow Developer Survey » selon lequel près de 90 % des développeurs utilisent Git, alors que Mercurial est le système de contrôle de version le moins populaire avec seulement 3 % d'adoption par les développeurs. Selon le billet de blog de Bitbucket publié par Denise Chan, l'utilisation de Mercurial sur Bitbucket est en baisse constante, et le pourcentage de nouveaux utilisateurs de la plateforme choisissant Mercurial est tombé à moins de 1 %.

Selon l’équipe, « Cette obsolescence nous permettra de nous concentrer sur la construction de la meilleure expérience possible pour nos utilisateurs ». C’est ainsi que « Cette année, nous nous concentrerons sur la création d'intégrations plus profondes afin d'améliorer l'automatisation et la collaboration. Nos améliorations rendront la planification, le code, les tests et le déploiement encore plus faciles et plus sûrs à partir de Bitbucket », lit-on dans le billet de blog.

Comment faire pour migrer et exporter les dépôts Mercurial ?

L’équipe Bitbucket recommande que les équipes de développement migrent leurs dépôts Mercurial existants vers Git. Pour le faire, elle propose différents outils de conversion Git qui sont sur le marché, y compris hg-fast-export et hg-git mercurial plugin.

Pour soutenir la migration de ses clients, Bitbucket a créé les ressources suivantes afin de fournir les connaissances et les outils nécessaires à une meilleure transition : un fil de discussion communautaire dédié pour discuter des outils de conversion, de la migration, des conseils et de l'aide au dépannage et un tutoriel Git qui couvre depuis les bases de la création de requêtes en mode pull, à la création de nouvelles bases et des Git Hooks.

Toutefois, pour ceux des clients qui préfèrent continuer à utiliser le système Mercurial, il existe un certain nombre de services d'hébergement Mercurial gratuits et payants, selon le billet de blog.

Sources : Bitbucket

Et vous ?

Que pensez-vous de ce changement ?
Quels sont les avantages de ce changement ?
Existe-t-il des inconvénients, lesquels ?
Quels commentaires faites-vous de l’avenir de Mercurial ?

Lire aussi

Intégration et livraison en continu avec TeamCity, Bitbucket et Azure, un tutoriel de Hinault Romaric
Intégration et déploiement continu avec TeamCity, Bitbucket et Azure, partie 3 : livraison continue sur Azure, un tutoriel de Hinault Romaric
Pipelines : quand l'intégration et la livraison en continu s'invitent dans Bitbucket
Atlassian lance Bitbucket Pipelines, pour étendre son service d'hébergement de code Bitbucket avec des fonctionnalités de déploiement continu

[dourouc05]

Juste pour mettre en évidence deux points : Atlassian décide de se focaliser sur Git grâce à un sondage réalisé sur une communauté plutôt pro-GitHub (donc Git) ; leur migration est simple : tout le contenu sur des dépôts Mercurial sera purement et simplement supprimé dans moins d'un an, peu importe s'il n'y a plus personne qui gère certains projets (qui seront donc perdus). Google avait fait ça mieux : au moins, les dépôts existants existent toujours, même s'ils ne sont qu'en lecture seule.

[earhater]

j'aurai au moins fait un zip du projet mercurial, créé un repo git en balancant les sources et supprimé le repo mercurial in fine ...

[Mathis Lucas]

PyPy quitte Mercurial pour GitHub et affirme que "l'open source est devenu synonyme de GitHub"
le projet s'attend à une meilleure visibilité et à plus d'engagements avec ce changement

Le projet PyPy, une mise en œuvre du langage Python écrite elle-même en Python, a annoncé avoir transféré son dépôt principal et son système de suivi des problèmes sur GitHub. En d'autres termes, PyPy quitte le système de contrôle de version Mercurial et rejoint la communauté open source de GitHub, propriété du géant des logiciels Microsoft. PyPy a déclaré que Mercurial reste "une excellente solution", mais le projet ajoute avoir rejoint GitHub pour une meilleure visibilité et un meilleur engagement de la communauté. L'équipe de PyPy estime que l'open source est devenu synonyme de GitHub et que le projet est trop petit pour lutter contre cela.

PyPy est un remplacement direct de l'interpréteur Python standard, CPython. Alors que CPython compile Python en un bytecode intermédiaire qui est ensuite interprété par une machine virtuelle, PyPy utilise la compilation juste à temps (Just-In-Time - JIT) pour traduire le code Python en langage d'assemblage natif de la machine. Ce qui permet de rendre l'interprétation du code Python nettement plus rapide. En fonction de la tâche effectuée, les gains de performance peuvent être spectaculaires. En moyenne (géométrique), PyPy accélère Python d'environ 4,7 fois par rapport à Python 3.7, certaines tâches pouvant être accélérées jusqu'à 50 fois ou plus.

Le projet était jusque-là hébergé sur Mercurial, mais le 29 décembre 2023, l'équipe de PyPy a annoncé la migration de son dépôt canonique et de son système de suivi des problèmes de Heptapod vers la plateforme rivale GitHub. L'équipe a expliqué que la migration de Mercurial vers GitHub est motivée par plusieurs facteurs. Elle dit avoir rencontré des difficultés pour suivre les problèmes et les contributions sur Heptapod. Dans son billet de blogue sur le sujet, Matti Picus, contributeur principal, a déclaré que le projet a besoin d'une visibilité plus large et d'un accès plus facile, deux choses pour lesquelles GitHub est réputé dans la communauté open source.

Dans le même temps, Picus estime que la prédominance de GitHub dans l'hébergement de projets open source offre au projet PyPy la possibilité de s'intégrer dans un écosystème de développeurs plus dynamique et plus actif. La plateforme unifiée de GitHub simplifie également le suivi des problèmes et du code, rationalisant ainsi le processus de développement. Picus a déclaré : « nous pensons toujours que Mercurial est un meilleur système de contrôle de version. Le modèle de branche nommée et l'interface utilisateur sont supérieurs. Mais… ». Dans son billet de blogue, Picus résume les raisons derrière ce changement comme suit :

• le dépôt Heptapod n'était pas bien indexé par les principaux moteurs de recherche ;
• depuis qu'Heptapod a renforcé son contrôle du spam, nous recevons des rapports selon lesquels les utilisateurs créent des problèmes pour ensuite les signaler comme étant du spam ;
• l'open source est devenu synonyme de GitHub, et nous sommes trop petits pour changer cela ;
• une grande partie du développement actuel est une réaction à la résolution de problèmes. Il est plus facile de suivre les problèmes interdépendants si tout le code se trouve sur la même plateforme ;
• la FAQ présente deux arguments contre cette évolution. Les notes Github résolvent en grande partie le point (1) : la difficulté de découvrir la provenance des modifications, mais pas entièrement. Mais le problème principal est le point (2), il s'avère que le fait de ne pas passer à GitHub est un obstacle à la contribution et au signalement des problèmes ;
• GitHub est plus riche en ressources qu'Heptapod. Nous pourrions ajouter des tâches CI pour remplacer une partie de notre infrastructure Buildbot vieillissante.

PyPy a déjà déplacé son référentiel par le passé. En 2010, il a mis le code sur Atlassian Bitbucket. Dix ans plus tard, il est passé à Mercurial, hébergé chez Heptapod. Une entrée de la FAQ, référencée par Picus, remarque que Git n'a pas d'équivalent aux branches nommées de Mercurial ; et que passer à GitHub juste parce que tout le monde le fait est "un argument sur des bases minces". Ce point de vue a maintenant changé. Expliquant un mouvement qui déprimera ceux qui croient que GitHub a déjà trop de domination, Picus a déclaré que le fait d'être hors de la communauté open source de GitHub peut être un obstacle à l'évolution d'un projet.

Selon le billet de blogue de Picus, il sera toujours possible d'utiliser Mercurial pour contribuer au projet PyPy, mais le code devra être transféré sur GitHub en utilisant les mêmes techniques que celles utilisées pour migrer le référentiel. En outre, ce changement modifiera quelque peu le flux de travail normal. Il n'y aura plus de flux de travail "commit directly to main", et les contributeurs utiliseront désormais la technique normale de git en créant une branche dérivée du dépôt et en soumettant une "pull request". De son côté, Heptapod n'autorise pas les forks personnels. Picus s'attend à un meilleur engagement de la communauté vis-à-vis de PyPy.

Dans le contexte plus large du développement de logiciels libres et open source, la migration de PyPy vers GitHub reflète une tendance à la consolidation sur GitHub, propriété de Microsoft. Cela a été reçu pour la plupart avec un sentiment d'inévitabilité et les avis révèlent que beaucoup de développeurs s'attendent à ce que d'autres projets sautent le pas afin d'avoir une meilleure visibilité et plus d'engagements. Certains critiques se sont toutefois demandés pourquoi Picus et son équipe n'ont pas choisi GitLab. « A-t-on pensé à GitLab ? Pourrait-il être envisagé ? Cela devrait être plus facile après le passage à git », indique un commentaire.

En réponse, Picus a déclaré que certains problèmes peuvent survenir lors de l'utilisation de GitLab et que cela pouvait être un point de friction pour les contributeurs du projet. Picus explique : « nous étions sur GitLab : foss.heptapod.net est une version amicale de GitLab. Le problème est la friction de l'interaction avec d'autres logiciels lorsqu'ils sont tous situés sur GitHub ». Un autre critique a écrit : « c'est un peu triste que ce soit vrai. Je suis moi-même coupable, je contribue à des projets sur GitHub plus souvent que sur n'importe quelle autre plateforme. Et lorsque je recherche des projets open source, le premier site que j'utilise est GitHub ».

Les discussions sur la toile font état de sentiments mitigés au sein de la communauté concernant la domination de GitHub. Si certains y voient une évolution positive pour les projets open source, d'autres s'inquiètent de la centralisation du pouvoir et des difficultés rencontrées par les petites plateformes pour attirer et retenir les grands projets. Le déménagement de PyPy pourrait potentiellement influencer d'autres projets open source, en centralisant davantage le développement de logiciels sur GitHub et en façonnant le futur paysage des collaborations open source. D'autres développeurs rejettent la faute sur la plateforme concurrente SourceForge.

« C'est en grande partie la faute de SourceForge. Ils avaient une avance considérable et ont complètement raté leur coup », a écrit un critique. Un autre a ajouté : « ils n'ont pas seulement raté leur coup, ils ont activement saboté la réputation qu'ils avaient acquise en ajoutant des logiciels malveillants aux logiciels. Non seulement c'était un énorme problème, mais cela a ruiné la réputation de nombreux projets FOSS auprès de personnes qui voulaient utiliser certains des logiciels open source les plus populaires auprès des consommateurs, comme Filezilla. Pendant ce temps, GitHub a gagné la confiance et la bonne volonté de beaucoup de développeurs ».

Source : PyPy

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de la décision de PyPy de quitter Mercurial pour GitHub ?
Partagez-vous l'avis selon lequel l'open source est devenu synonyme de GitHub ?
Comment GitHub a-t-il acquis une telle domination dans la communauté open source ?
Que pensez-vous de l'avis des critiques qui rejettent la faute sur SourceForge ?
Selon vous, la domination de GitHub va-t-elle continuer à se consolider à l'avenir ? Pourquoi ?

Voir aussi

Apache Software Foundation rejoint la communauté open source de GitHub et met fin à son propre service git

Un rapport de GitHub démontre la forte dépendance mondiale aux logiciels open source, si ces logiciels continuent de gagner en popularité, les logiciels propriétaires sont toujours bien vivants

Le projet Kyoto quitte à son tour GitHub en guise de protestation contre les porteurs de projets qui utilisent l'open source pour aboutir à des solutions logicielles dont ils ferment le code source