Please read https://boinc.berkeley.edu/trac/wiki/SoftwareTesting
-- David
On 8/4/2017 3:38 PM, Laurence Field wrote:
Hi David,
On 04/08/17 23:17, David Anderson wrote:
It's simple:
1) fork master, e.g. to client_release_xxx. It's not stable at this point.
2) test client_release_xxx (e.g. using Alpha testers) fix bugs, repeat. Now it's
stable.
3) only backport bug fixes to client_release_xxx. It remains stable.
You can also build and test from master, fix the issues then make the release. A
branch can then be created but would only be updated to include major issues and
not any new features. Once the master is 'stable' it should in theory never break
again as changes in the PRs should have already been tested. If we are able to
have nightly builds with automated tests, this should speed up the process on the
long term.
We've always used this approach for the client, and it's worked perfectly.
That does not mean it is necessary it is the best method. This kind of
argumentation is not Computer Science.
We can use the same approach for server if we create
a distributed testing system based on Beta projects (analogous to the client
Alpha test)
Having a versioned release of the server would be helpful. I hope that we can have
working server packages for Debian and CentOS soon. I don't think we need to
target any other platform but please let me know if there are others.
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.
_______________________________________________
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.
