"boinc_dev" <boinc_dev-boun...@ssl.berkeley.edu> wrote on 01/12/2018 02:54:44 AM:
> From: Laurence <laurence.fi...@cern.ch> > To: <boinc_dev@ssl.berkeley.edu> > Date: 01/12/2018 02:56 AM > Subject: Re: [boinc_dev] server stable release issues > On 11/01/18 22:29, Marius Millea wrote: > > > >> 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 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" > > 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. > Just my 2 cents. 1) The server should strive to be compatible with versions of the client released with the past few years (maybe 4-5 years). 2) I vote in favor of semantic numbering. Since we might test version 1.2 of the server and then release it in say Feb 2018 as version 1.2.5. Master might move on to version 1.3 (assuming same dev/release odd/even numbering as client). Then in June we might find a critical bug and fix the 1.2 release and release it as 1.2.6 but also start a 1.4 release cycle from the 1.3. It would be unclear with a date oriented numbering what we would call 1.2.6 and 1.4.1. This assumes that we will create stable release branches for the server like we do for the client (which is something I am in favor of). thanks, Kevin _______________________________________________ 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.
