I am running one project and I use boinc version 4.13. Is it safe for me to upgrade to boinc version 4.19. I have no problems with version 4.13 yet. I have not yet finished any project so I don't know if there will be some problems to upload to the server when I finish the project.

---

hi hogni,
i have seen a few people reporting problems when upgrading to 4.19. I suggest making a backup prior to your upgrade so you can roll-back...

There is a major upgrade to BOINC promised. I don't know the latest news on that, but if you are happy with 4.13 you may prefer to wait a bit.

---

I've changed to 4.19, and the only problems i had were with Predictor, not with boinc. since it is now the only downloadable version on the <a href="http://boinc.berkeley.edu/download.php">boinc-download-page</a>, I think it's fair to say: It's official!
S@H and CPDN had no problems so far (XP an Intel and AMD).

---

Grüße vom Sänger

&gt; There is a major upgrade to BOINC promised.

No hints of any general release plan, and I think after the speed of the jump from 4.13 to 4.19 they'll be very cautious about how it's released. It's still very much a case of use at your own risk.

I'm intending to upgrade to 4.19 next week, primarily because it should fix the problems of
1) models crashing when a periodic benchmark suspends the model before it's properly started up and
2)the lack of an automatic retry on upload and download failures.

---

"The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer

&gt; &gt; There is a major upgrade to BOINC promised.
&gt;
&gt; No hints of any general release plan, and I think after the speed of the jump
&gt; from 4.13 to 4.19 they'll be very cautious about how it's released.

Hello Thyme,

the 'major Upgrade' is the devoper version 4.62. I don't use it since i'm no developer and do not have enough zeal/recklessness to just try it.
The numbers race from 4.13 to 4.19 in such a short time is explained by Rom Walton (fulltime Projekt developer) in several threads in S@H-s number crunching boards.

Here's a c&amp;p from <a href="http://setiweb.ssl.berkeley.edu/forum_thread.php?id=11138#75077">this post</a>:

<b>citation:</b>
&gt; FWIW, releasing clients as fast as they can to the alpha team is a regular
&gt; thing when Berkeley wants to get a new client out the door. Build it, give it
&gt; to alpha, wait for a few bugs, fix the bugs, and start over.
&gt;
&gt; It's more effective than I thought it would be. Ideally, I think we need a
&gt; few days of holding between the last release and releasing to the public, but
&gt; they don't pay me the big bucks to make those kinds of decisions. :-)

I guess you can say I'm copying the MS playbook a little bit, once you reach ZBB( Zero Bug Bounce, all the bugs that need to be fixed for release), you freeze the branch and then only accept priority one severity one bugs for the duration of a test pass. During the process, new releases are released as needed, each new release is referred too as a dot release.

Since I can't add in additional version information due to BOINC's design, I just increment the minor version util we reach our target. What some people loose site of is, it was the 4.13 release with a few additional fixes, so after 4.14 was relaesed and tested, you can say that the test pass began and we just needed to shore up a few additional issues. Keep in mind though, 4.13 had already been released to the public, and two of the bug fixes we took for 4.14 had already been in alpha for a month or two.

Each additional release didn't require a restart of the full test pass, just a few additional tests around the bug fix area.

Changing the minor version and rebuilding frequently has an additional advantage, it reduces confusion about what bugs are fixed when, and keeps everyone in sync with what is going on. Releasing private builds, or re-releasing with the same build number only adds confusion to the process.

----- Rom

BOINC Development Team, U.C. Berkeley

<b>end citation:</b>

---

Grüße vom Sänger

&gt; The numbers race from 4.13 to 4.19 in such a short time is explained by Rom
&gt; Walton (fulltime Projekt developer) in several threads in S@H-s number
&gt; crunching boards.

Causes a lot of confusion, though. See this board. It would be fine if upgrades were always troublefree, but reports show that they are not.

I agree that 4.19 is the recommended version, and it would lessen the confusion if CPDN now moved to this one.

---