The first block is for BRP4, the last one for BRP3. (The plan class name includes "BRP3" because changing it would require some more code change without any benefit.)
But they are differnt applications, just happening to have the same "user friendly" name http://einstein.phys.uwm.edu/apps.php. That should not cause problems even if BRP4 apps should increase versions numbers , right?
No, it should not cause problems, it's just not that user friendly to have on one hand talk about BRP3 and BRP4, while the app has the same name for both, and the newer app even has a lesser version number.
Im my BOINC I see only BRP3, some old ones with v1.00, some new ones with v1.08 (at least that's the first impression, I know that it's the other way around).
Perhaps you should clarify that somewhere in a news item, as text in the apps page, in a dedicated thread here, or whatever.
An idea on how to make it easier for users to tell if any of their workunits are BRP4: Put BRP4 near the beginning of the workunit name, instead of expecting the users to be able to decode the application names that contain BRP3 instead. I'm not sure the developers would like this as much, since it leaves less space in the workunit names for what they are already putting there.
Just curious - why not go up in version number instead of down?
A guess only - they didn't build some of their server code in a way that allows adding higher version numbers without a lot of work. If they had built it to handle higher version numbers more easily, that's what they would probably be using.
By convention 1.00 (actually x.00 when we used different major version numbers for different platforms) is the application version that a run was started with. Below 1.00 are (usually) experimental versions; if the application gets improved over the time of a run, it will get higher version numbers.
I see 2 BRP3 and no
)
I see 2 BRP3 and no BRP4?
Tullio
Hi The first block is for
)
Hi
The first block is for BRP4, the last one for BRP3. (The plan class name includes "BRP3" because changing it would require some more code change without any benefit.)
HB
RE: But they are differnt
)
No, it should not cause problems, it's just not that user friendly to have on one hand talk about BRP3 and BRP4, while the app has the same name for both, and the newer app even has a lesser version number.
Im my BOINC I see only BRP3, some old ones with v1.00, some new ones with v1.08 (at least that's the first impression, I know that it's the other way around).
Perhaps you should clarify that somewhere in a news item, as text in the apps page, in a dedicated thread here, or whatever.
Grüße vom Sänger
RE: Reset the version
)
Just curious - why not go up in version number instead of down?
An idea on how to make it
)
An idea on how to make it easier for users to tell if any of their workunits are BRP4: Put BRP4 near the beginning of the workunit name, instead of expecting the users to be able to decode the application names that contain BRP3 instead. I'm not sure the developers would like this as much, since it leaves less space in the workunit names for what they are already putting there.
RE: RE: Reset the version
)
A guess only - they didn't build some of their server code in a way that allows adding higher version numbers without a lot of work. If they had built it to handle higher version numbers more easily, that's what they would probably be using.
By convention 1.00 (actually
)
By convention 1.00 (actually x.00 when we used different major version numbers for different platforms) is the application version that a run was started with. Below 1.00 are (usually) experimental versions; if the application gets improved over the time of a run, it will get higher version numbers.
BM
BM