Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic Versioning in Package Managers #22

Open
jbenet opened this issue Jun 24, 2014 · 6 comments
Open

Automatic Versioning in Package Managers #22

jbenet opened this issue Jun 24, 2014 · 6 comments

Comments

@jbenet
Copy link
Owner

jbenet commented Jun 24, 2014

Reading http://crates.io/manifest.html it mentions a section on following semver:

Before you reach 1.0, anything goes.
After 1.0, only make breaking changes when you increment the major version. In Rust, breaking changes include adding fields to structs or variants to enums. Don’t break the build.
After 1.0, don’t add any new public API (no new pub anything) in tiny versions. Always increment the minor version if you add any new pub structs, traits, fields, types, functions, methods or anything else.

Wait, why can't we just automatically version code based on this? It's hard for other languages, but Rust compiler is probably able to generate semver for us. It would certainly make less code break if semver was definitely followed.

The one downside is less flexibility for the authors. But when doing semver, you don't really have that flexibility anyway-- versioning is spec-ed out for you.

@jbenet
Copy link
Owner Author

jbenet commented Jun 24, 2014

cc @wycats @carllerche

@jbenet
Copy link
Owner Author

jbenet commented Apr 14, 2015

@mafintosh your bot idea reminded me of this.

@mafintosh
Copy link

@jbenet the bot could run some sort of heuristic on the code and suggest major/minor/patch

@yoshuawuyts
Copy link

Not sure what the bot idea is, but any assistance in semver would be tremendously beneficial. For npm, hooking a check into a prepublish script could be neat.

@seidtgeist
Copy link

@hishamhm
Copy link

You can't automate semver all the way because semantic changes to the code also break compatibility, and cannot be mechanically detected in general. A function may change its behavior but not its type signature, a struct can change they way it is used but the fields remain the same. An automated tool won't catch this.

So, you can write a tool that detect lots of situations and say "hey, you must increment the major version here!" but you can't write a tool that is able to look at code and say "this can be a tiny version increase, no API behaviors have changed."

Yes, you can use test suites as a proxy for detecting semantic changes in API behaviors beyond type signatures and data structures and that would improve things — you'd be able to detect more "you must increment major" situations. But it can also only go so far, because in practice one can't test for every possible input/output combination so you still can't be 100% sure; the tool wouldn't be able to ensure a release is really "tiny-safe".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants