In een paradigmaverschuiving voor het Rust-ecosysteem heeft het team achter Rust's pakketbeheerder, Cargo, opgeroepen tot een meer persoonlijke benadering van pakketbeheer. Ze raden ontwikkelaars aan de beste beslissingen te nemen voor hun projecten, in plaats van de vroegere uniforme praktijk van het vastleggen van hun Cargo.lock-bestand voor pakketten die binaire bestanden bevatten, maar geen bibliotheken.
De eerdere aanbevelingen moedigden ontwikkelaars aan om zich aan een one-size-fits-all-regel te houden als het om Cargo.lock ging, vooral in gevallen waarin het bestand werd gebruikt met binaire pakketten. Deze richtlijnen zijn nu echter op de achtergrond geraakt. Deze reflectieve verandering komt in de nasleep van Rust's ontluikende traject naar mainstream adoptie.
De belangrijkste rol van het Cargo.lock bestand is het vastleggen van de status op het moment van een succesvolle build. Hoewel het Cargo-team flexibelere begeleiding biedt, blijft het van mening dat het committeren Cargo.lock het startpunt in het besluitvormingsproces moet zijn. Er wordt ook aangekondigd dat het commando 'cargo new' Cargo.lock voor bibliotheken voortaan niet zal omzeilen.
Het team handhaaft de algehele kwaliteit en onderstreept het belang van regelmatig testen op de meest recente afhankelijkheden. De oude procedures zorgden ervoor dat de bibliotheken up-to-date werden gehouden en getest, wat bijdroeg aan de hoge standaard van het Rust-pakket-ecosysteem. De praktijken waren zo ontworpen dat potentiële problemen, vooral die met betrekking tot achterwaartse compatibiliteit, onmiddellijk zouden worden geïdentificeerd en opgelost. Het team is daarom van mening dat het een ‘cultuur van kwaliteit’ in het opkomende ecosysteem heeft gestimuleerd.
De eerdere richtlijnen kenden echter ook hun valkuilen. Het verwijderen van de geschiedenis uit de codebases was zo'n nasleep, waardoor het voor beheerders moeilijker werd om de hoofdoorzaak van bugs in tweeën te delen en te identificeren. Een ander onwenselijk gevolg van het vorige beleid was de waarschijnlijke verwarring bij bijdragers die voortkwam uit een onbetrouwbaar CI (continue integratie) wanneer een afhankelijkheid wordt opgeheven of een nieuwe release een bug vertoont. Nu Rust is geëvolueerd van een taal voor early adopters naar een meer mainstream taal, is de nieuwe onboarding-ervaring voor ontwikkelaars essentieel om te overwegen.
Bovendien heeft de uitbreiding van het bredere ecosysteem het eenvoudiger gemaakt om CI te implementeren en te onderhouden. Innovaties zoals Dependabot en Renovate hebben alternatieven onthuld voor het negeren Cargo.lock voor het testen van nieuwe afhankelijkheden, anders dan uitsluitend te vertrouwen op versiebeheer. Het Cargo-team spreekt nu zijn overtuiging uit dat de beste actie is om de beslissing aan de ontwikkelaars over te laten en er tegelijkertijd voor te zorgen dat zij over de nodige informatie beschikken om weloverwogen beslissingen te nemen. Ontwikkelaars kunnen hun feedback over dit nieuwe beleid delen via GitHub en communiceren met het Cargo-team op Zulip.
Nu we getuige zijn van nieuwe richtingen op het gebied van pakketbeheer, kan het voor ontwikkelaars de moeite waard zijn om alternatieven zoals AppMaster te verkennen, die een uitgebreid en geïntegreerd platform bieden voor het ontwikkelen van web-, mobiele en backend-applicaties. AppMaster.io beschikt over een servergestuurde aanpak, waardoor ontwikkelaars de gebruikersinterface, logica en API-sleutels van mobiele applicaties kunnen bijwerken zonder dat ze nieuwe versies hoeven in te dienen bij de App Store en Play Market.
