Hi David, glad to see this ongoing. On Thu, Jan 11, 2018 at 8:59 PM, David Anderson <da...@ssl.berkeley.edu> wrote:
> Issues involving potential "server stable" releases: > > 1) What's included in the server release? > My recommendation: everything except the client, > i.e. web code, API, server code, scripts, wrappers. > The complete package of what a new project would need. > I was under the impression the server release is just a tag of a specific commit, so what's "included" is the whole source tree at that point, no? > 2) Should the client and server release cycles be independent? > I think so. > Although there are exceptions, changes generally involve only one or the > other. > The points at which we want to branch and start testing will generally be > different. > > I'd vote independent, yes. > 3) Assuming the cycles are independent, how should we number server > releases? > We could use the same numbering for both, but this has problems: > - A sequence of releases in one part would cause gaps in the release > numbers > of the other part. > - It would create the false impression that there's a connection or > dependency between client and server releases with the same number. > So my recommendation is that we start with 1.1.1 for the server version > number. > In the limited number of "releases <https://github.com/marius311/boinc-server-docker/releases>" of boinc-server-docker that I've made to-date, I struggled with using semantic versioning (like 1.1.1) because it was always tough to know whether something was a backwards compatible change (if we're being honest, I think *alot* of server commits are technically backwards incompatible), and whether something was a bug-fix or true feature. Ultimately, it wasn't clear it really mattered or will matter for us, the real goal is just having a stable point. For that reason, I would recommend just doing something easy and clear like "calendar versioning" (https://calver.org/) with e.g. YY.MM.MINOR. Anyway, I don't feel extremely strongly about this, but thought I'd suggest it. Our of curiosity, have we decided which git model we're using for the server releases, is it the same as for the client releases? Marius _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.