On Wed, Feb 29, 2012 at 10:22 AM, David A Case <case.biomaps.rutgers.edu> wrote:
> 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.
I was thinking more along the lines of this being more for developer
use. The current patch_amber.py way of handling bugfixes and reporting
the patch level is great. Individual program versioning would just be
a way to keep track of what's going on 'under the hood'. You're right
in that it will result in different programs having different version
numbers, but the way I was thinking about it users would use the
output from 'patch_amber.py --patch-level' when reporting bugs while
the program's internal version string would be an additional check to
make sure patches have been properly applied. So if I type 'cpptraj
--version' and get 12.3 I know that the latest bugfix to actually
affect cpptraj was 3.
-Dan
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 29 2012 - 08:00:01 PST
