Replies: 1 comment
-
I think this is typically not the job of the package manager itself. Often there are adjacent projects that help with this, like: https://github.com/crate-ci/cargo-release for cargo. We could come up with something similar, but i dont think tieing the package manager itself to a svc system is good? We could think about a subcommand that does the bumping etc, like |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
James raised a point here that manually specifying versions in the manifest easily leads to pitfalls in a version controlled project - ie, there's a chance one might bump the version in the manifest and fail to publish the package, or publish the same version again, thus overwriting a previous release. There's also nothing tying git tags and (GitHub) releases to specific package versions, other than convention. Buffrs just takes the manifest at face value for what the package version should be, and it's up to developers to ensure the publication workflow is sane, using external tooling.
While this is standard practice across common package managers like Pip, Cargo, NPM, etc. that doesn't mean we need to follow the beaten path. Version control is near universal in today's software engineering, and so is git. Maybe it's time we integrate more deeply with it, and delegate the source of truth for package version to git tags.
If we do end up going down that path, there are a number of decisions to be made, so I'm also reserving this space for brainstorming design ideas.
Beta Was this translation helpful? Give feedback.
All reactions