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.

Reply via email to