Just a quick question
Closed this issue · 2 comments
Hello!
My name is Reed, and I'm a software engineering researcher at Sandia National Laboratories in the US. I've created an issue on your repo just to ask a quick question. If you don't have time or don't care to respond, feel free to ignore me and/or delete this issue.
Where I work, we have a very diverse ecosystem of cutting-edge research codes spanning every discipline you could imagine. I'm part of our software engineering research department, and it's our job to keep that ecosystem robust and healthy. Part of that means helping our scientists to adopt good software practices. Right now, my mind has been on software versioning/release schemes (e.g. semantic versioning).
In order to build a case for/against getting my people on-board with the practice, I figured I should ask people who already use versioning to release their software to see what they think. So I gathered up a list of scientific software repositories on GitHub, then I selected those that tracked versioned releases, that were reasonably active, etc. Finally, I picked a handful of those repos and decided to reach out to them. You were on that list.
Anyway, here's the question:
What do you believe are the benefits (or drawbacks) of having versioned releases of your software (i.e. 1.0.0, 1.1.0, 2.0.0...)? When should someone start thinking about versioning/releasing their code?
Just a sentence or two, that's all I need. For context, imagine the preceding sentence is this: "But don't just take my word for it, just listen to what this accomplished computational geophysicist has to say!"
Thank you so much!
Reed Milewicz
rmilewi@sandia.gov
Hi Reed,
Thanks for reaching out. Well I would start by saying that I do not believe there is one versioning paradigm to rule them all. I would encourage one to release versions frequently. My preferred approach is to develop code on a dev branch and then merge to master once it's complete, passes tests, etc. Ideally one would use that opportunity to release a new version. But what about numbering?
I generally follow this stack overflow answer: major, minor, build numbering. So every version under 1.x should be backwards-compatible with 1.0. 1.1 might add a new minor feature, 1.1.1 might be a bug fix. A new major release (e.g. 2.0) should coincide with a version that either breaks backward-compatibility or introduces a significant upgrade e.g. a new module that brings a raft of new functionality. If you have to thoroughly overhaul the documentation, then this is probably a good indication you need to release a new major version.
I deviate from that stack overflow answer in that I usually start at 0.1 for experimental code. I will not release version 1.0 until I feel that my API is stable. I'm getting close to that for this repository. Once pycurious passes the JOSS review, I will release version 1.0.
Hope my answer is helpful to you.
Kind regards,
Ben
Yes, this is very helpful! Exactly the sort of advice that my researchers need to hear. Thank you so much for taking the time to respond! :-)