On Wed, Feb 29, 2012, Daniel Roe wrote:
>
> I know this subject was discussed somewhat at the developer's meeting
> but I wasn't sure if a consensus had been reached. From the name of
> the AmberTools manual in the GIT repo I assume that AmberTools will be
> version 12 for this release? If that is the case then it seems that
> programs can follow a simple version format:
>
> 12.<bugfix#>
>
> where <bugfix#> gets updated whenever a bugfix is written for that
> program, with the number matching the number of the bugfix. I think
> this will really simplify troubleshooting.
I guess it's OK, although the patch_amber.py script will report the latest
update number as well. And since updates are no so easy, I think most people
will automatically have them all.
The problem with your scheme is that the "current patched" version of
AmberTools12 would end up with all kinds of version numbers. antechamber
might be at version 12, whereas cpptraj would be at version 12.3, and so on.
Since problem reports are not always related to a single program, this could
cause confusion, or users would have to try to track down the version numbers
for a variety of programs, and might not even know which program was the
culprit. Plus bugfixes that update force field files (for example) would not
be represented in the version number of any programs.
I'm inclined to think that we should just ask the user to report the output
from '$AMBERHOME/patch_amber.py --patch-level' when reporting problems.
...still thinking...other comments are welcome...dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 29 2012 - 07:30:02 PST
