On 1/11/2018 1:29 PM, Marius Millea wrote:
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?
Yes; the question is what part of the tree is "stable". For example, in the client_release_xx branches, only the client-side software is stable (i.e. tested); the server software is just a random snapshot.
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.
Most server software releases would involve changes to the DB structure and would therefore be backward incompatible. In the client, our convention is that test and release versions have odd and even minor versions respectively. This is handy for keeping things clear.
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?
I had assumed so (this is described here, BTW: https://boinc.berkeley.edu/trac/wiki/AdminReleaseManagement -- David _______________________________________________ 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.
