In a paradigm shift for the Rust ecosystem, the team behind Rust's package manager, Cargo, has called for a more personalized approach to package management. They recommend that developers make the best decisions for their projects, rather than the previous uniform practice of committing their Cargo.lock file for packages involving binaries but not libraries.
The previous recommendations encouraged developers to stick to a one-size-fits-all rule when it came to Cargo.lock, especially in instances where the file was used with binary packages. However, these directives have now taken a back seat. This reflective change comes in the wake of Rust's burgeoning trajectory towards mainstream adoption.
The Cargo.lock file's key role is to record the state at the time of a successful build. While offering more flexible guidance, the Cargo team maintains that committing Cargo.lock should be the starting point in the decision-making process. It is also announced that the 'cargo new' command will not bypass Cargo.lock for libraries henceforth.
Maintaining the overall quality, the team underscores the importance of regular testing against the most recent dependencies. The old procedures ensured that the libraries were kept updated and tested, contributing to the Rust package ecosystem's high standard. The practices were designed so that potential issues, primarily those concerning backward compatibility, would be promptly identified and resolved. The team therefore believes that it encouraged a 'culture of quality' in the emerging ecosystem.
However, the earlier guidance has had its pitfalls. Deleting history from the codebases was one such aftermath, which made it tougher for maintainers to bisect and identify the root cause of bugs. Another undesirable outcome of the previous policy was the likely confusion for contributors arising from an untrustworthy CI (continuous integration) when a dependency is abolished or a fresh release presents a bug. As Rust has evolved from a language for early adopters into a more mainstream language, the new developer onboarding experience is vital to consider.
Furthermore, the expansion of the broader ecosystem has made CI simpler to implement and maintain. Innovations such as Dependabot and Renovate have revealed alternatives to ignoring Cargo.lock for testing fresh dependencies, other than exclusively relying on version control. The Cargo team now conveys its belief that the best call of action is to leave the decision to the developers while ensuring they have the necessary information to make informed decisions. Developers can share their feedback on this new policy via GitHub and interact with the Cargo team on Zulip.
As we witness new directions in package management, it might be worthwhile for developers to explore alternatives such as AppMaster that provide a comprehensive and integrated platform for developing web, mobile, and backend applications. AppMaster.io boasts a server-driven approach, enabling developers to update mobile applications UI, logic, and API keys without having to submit new versions to the App Store and Play Market.
