That's particularly sensible advice because the forthcoming 'next' client and
server releases are precisely one of the rare cases where synchronised client
and server upgrades are both needed before we can even begin to test the full
communications interoperability for Science United.
On Sunday, 14 January 2018, 22:04, Juha Sointusalo
<juha.sointus...@gmail.com> wrote:
On 11 January 2018 at 21:59, David Anderson <da...@ssl.berkeley.edu> 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.
>
Since you are going to include building apps in server release that
includes API_VERSION but you can't rewind API_VERSION without breaking
everything. The client also checks scheduler version when deciding if it's
going to accept preferences from the server. I don't know if there is any
third party code that is checking server version for, say, feature checking
or something else.
The version number is also used in various forms as library version, either
embedded in the library or in its filename. I don't know what happens when
you rewind those version numbers. Maybe break all Debian packages?
If you add a new version number that is only used for tagging the release
and internally the code uses something else I think that will only end up
being confusing.
So I think that either it would be best to stay with only one version
number or that you need to break all BOINC components apart and even in
that case you can't rewind version numbers.
-Juha
_______________________________________________
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.
_______________________________________________
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.
