search

jbenet / random-ideas

random ideas
juan.benet.ai
324 stars 12 forks source link

Automatic Versioning in Package Managers #22

Open jbenet opened 10 years ago

jbenet commented 10 years ago

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 commented 10 years ago

cc @wycats @carllerche

jbenet commented 9 years ago

@mafintosh your bot idea reminded me of this.

mafintosh commented 9 years ago

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

yoshuawuyts commented 9 years ago

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 commented 9 years ago

Related: https://github.com/boennemann/semantic-release/ cc @boennemann

hishamhm commented 8 years ago

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".