On 11/01/18 22:29, Marius Millea wrote:
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.
They have to be. Once released there is little control over versions
used. Volunteers can have any client version and projects can have any
server version. Hence there is no build/release/version link between the
client and server. They are linked by RPCs which should be
documented/version/tested independently and always be backwards compatible.
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.
The server must always be backwards compatible with the client. The
general approach is roll forward with versioning. Hence, the most
important aspect is that the version numbers are incremental. Try to
avoid adding too many semantics to them. The basic major.minor.patch
semantics will lead to divergence of version number between the client
and the server. This would be an argument for having them in separate
repositories. But practically it does not matter.
Cheers,
Laurence
_______________________________________________
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.
