On Sat, Feb 21, 2015, Gerald Monard wrote:
> Then something like "Amber14.1" would be more meaningful: "minor"
> revision, only the free stuff is changed. It won't confuse users since
> they have paid for the Amber14, minor releases included. Next major
> release would be Amber16. No odd numbers anymore. It also leaves some
> time (until the '16 release) to re-factor the directories and decide if
> we drop the AmberTools naming.
A couple of points along this thread:
1. We can't merge the AmberTools and Amber source trees together. The
split between the AmberTools stuff and the pmemd stuff is there because
they fall under different licenses. Intermingling the trees would just
confuse that issue.
2. We can't ask Amber14 licensees to do a fresh download: that would be a
nightmare, as many people won't have kept their authentication information; or
the person who originally took out the license is gone, etc.
3. I'm toying with the idea of providing a script (with the upcoming
AmberTools release) that would rsync the pmemd-related material from
an existing amber14 location into a new directory tree, rooted at
.../amber14.1, that would also contain the new AmberTools files. This
would avoid potential problems from asking people to download the new
AmberTools on top of their current versions, and would avoid the requirement
of a fresh download of Amber14. (People that license Amber14 after the April
release might get a tarball rooted at the .../amber14.1 location.)
....dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Feb 21 2015 - 08:00:04 PST
