> On Feb 21, 2015, at 10:52 AM, David A Case <case.biomaps.rutgers.edu> wrote:
>
> 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.
I agree. This is probably one of the more important distinctions we make. For people that just want to *use* Amber, it doesn’t *really* matter where the source code lives... all the programs get dumped to the same place, anyway. The people that actually care about the source code directory structure are probably more likely to try modifying it and therefore probably care more about licensing issues.
I’m obviously not privy to private conversations not including me, but based on my experience on the mailing list and private emails sent to me, the directory structure and version confusion accounts for ca. 0% of the questions I see.
> 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.)
This is asking for trouble, I think. It’s going to make “fresh” installs more difficult and it will be *way* too easy to break the update_amber bookkeeping scheme in a convoluted way (I can almost guarantee it would happen). I see this heading down the AmberTools 1.5 -- Amber 11 rabbit hole. I can elaborate if more details are needed.
It would be great to come up with a scheme to limit any version/provenance confusion introduced by the naming of our directories, files, product brand, or anything else we do on that front. But I think one of the most important strides we’ve made in recent years is the improvements to the simplicity of getting up-to-date and installed quickly and easily.
If we assume that no amount of improved clarity in product or branding is worth regressing on ease of use, updating, or installation (and that Dave’s reasons for not creating a new Amber14.tar.bz2 fall into this category), then we have some constraints about what we can do (shown below). If people disagree with my assumption, then we should discuss how much of that simplicity we’re willing to sacrifice.
1. We are stuck with amber14/ as the root directory (no real workarounds here).
2. We should keep the same general directory structure (i.e., AmberTools/src/... and src/...)
3. We should limit the number of files we move around.
Also, update_amber reports version information as so:
swails.batman /usr/local/amber14 $ ./update_amber --version
Version is reported as <version>.<patches applied>
AmberTools version 14.26
Amber version 14.10
So we should factor this into the decision about what to name the versions. Maybe nobody looks at this so it won’t cause confusion if we call the “new” version 14.1 and our AmberTools version reported by update_amber goes from 14.26 to 14.1 to 14.1.1. And Amber 14 goes from 14.10 to 14.1.??.
As a final note, I’ll say that update_amber was designed to track multiple components (more can be added or subtracted easily), but it assumes that *everybody* has either *all* or *none* of every component (so moving to 1 component where some people have 90% and others have 100% is not supported). The components are given separate names. The minor version numbers are used to track patch numbers, major ones are also used as part of the bookkeeping (so I’m not sure how hard 14 -> 14.1 would even be... maybe easy).
There is some flexibility here, but I would very much like to limit the purely aesthetic changes I need to make to update_amber, since the version numbers are used as part of the update bookkeeping mechanism as well.
Lastly, I’ll also point out that there is a fairly flexible “--upgrade” mechanism in update_amber that can do quite a lot (although it should have the end-result of giving an equivalent setup to someone that downloads and installs everything from scratch).
All the best,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Feb 21 2015 - 22:00:02 PST
