Hi Dave,
> > > After an update of AmberTools, we then have two versions of
> everything.
> What would we ship to people who buy Amber12 *after* a staggered
> update
> of AmberTools?
That is one option. The approach we have now is essentially"
1) Get your copy of AMBER
2) Get the latest copy of AMBERTools
3) Untar amber tools
4) Go get the ambertools bug fixes
5) apply ambertools bugfixes
6) untar amber
7) go get the amber bugfixes
8) apply amber bugfixes
9) compile ambertools serial
10) test ambertools serial
11) compile amber serial
12) test amberserial
13) compile ambertools parallel
14) test ambertools parallel
15) compile amber parallel
16) test amberparallel (note you really have to run this a bunch of times
with different core counts)
17) compile cuda
18) test cuda
19) compile cuda_parallel
20) test cuda_parallel
Maybe people disagree with me here but in my opinion this completely crazy!
Even if we don't try to consolidate the compilation and testing in some
smart way, say where you tell the configure script what you want to build.
E.g. ./configure -serial -mpi -cuda -cuda_mpi gnu
At the very least I think we should seriously consider the distribution that
we give new people buying the code to be AMBER11+Patches. Then those
downloading AMBERTools should get AMBERTools1.5+bugfixes.
I still think that we should combine everything into AMBER12 - The version
we initially ship is AMBER12+AMBERTOOLS12 vanilla. Then when there are
bugfixes (and we have a SINGLE bugfix location with application script) we
update the versions we distribute as well. Thus the AMBERTOOLS12 we offer
for download should incorporate the latest patches. I don't know anybody who
just applies a single patch and not others so I don't think we need to cater
to that - they can hack that in themselves if they really want.
This way we can version things as:
AMBER12.0.0tar.bz2 (which is the complete AMBER)
AMBERTools12.0.0tar.bz2 (which is AMBERTools, a subset of the
AMBER12.tar.bz2 file)
Then when we have bugfixes, say we have bugfixes 1 to 3 that are in pmemd
and 4 and 5 that are in leap. We would increment the counters for both.
You'd apply the same bugfix file to both with an application script that is
smart to detect if you have full AMBER or 'amberlite'.
Then we'd distribute:
AMBER12.0.5.tar.bz2 and AMBERTools12.0.5.tar.bz2 implying they already
include to bugfix 5.
When we choose to update AMBERTools, say AMBERTools12.5 it will of course be
backwards compatible by definition. [oh look a flock of flying pigs...] ;-)
Then the versions we distribute would be:
AMBER12.5.0.tar.bz2 (We assume we roll all bugfixes into the 12.5 release)
and
AMBERTools12.5.0.tar.bz2
We only charge for AMBER versions that are a full release. This gives us the
option to have the .5 release be only bugfixes for pmemd, sander etc or some
minor feature updates etc if we wanted to. Either way we would include a
script that would upgrade the tree from AMBER12.0.X or AMBERTools12.0.x to
AMBER12.5.x (and AMBERTools12.5.X)
This seems perfectly reasonable to me. Much more understandable from a user
perspective and just needs a bit of discipline to make sure things are
versioned properly, people take the time to write their updates within this
patch framework / don't create their own custom building procedure etc.
Alternatively we can stick with the anarchy if we want and just watch things
slide more and more into general confusion while our competitors get their
acts together.
> > > We would still be kind of obligated to support the "official
> Amber12" package for two full years.
>
> > Many many people have asked me why we don't just have a single
> unified
> > build and test system.
>
> This is useful information. I handle all the license correspondence,
> and have
> never had anyone comment or complain about this issue. But we can
They don't complain from a license perspective. The prof who buys the
license is happy as larry. The poor student who gets tasked with installing
it everywhere is the one who shakes their head in dismay. And they'd never
email a full prof to say this. ;-)
> easily
> have a single unified build and test system, with smart Makefiles that
> detect
> what is there. That is a separate issue from the question of whether
> we
> offer a "complete Amber12 package" with "blessed" versions of
> AmberTools.
Agreed. But I think what I propose above makes sense since it keeps AMBER
together as a single unified brand which I think is important.
In this approach when we release AMBERTools12.5 we also designate that
AMBER12.5 and that is the one we consider blessed and support. It is just
that the AMBER parts of AMBER12.5 might just be minor bugfixes and updates
rather than the larger changes expected in AMBERTools 1.5.
> In the end, maybe this just comes down to whether users download one
> tarball
> or two. Maybe we should be thinking more creatively about how get
> money
> coming in for Amber, and still be able to upgrade all components
> (including
> pmemd) in a way that is (a) less clunky than bugfix.17; (b) doesn't
> destroy
> people's incentive to pay us again when Amber13 comes out.
Agreed. And I think the idea above. Of updating the version we distribute
and having point updates of AMBER be free. Then we keep AMBER and AMBERTools
updates in sync.
All the best
Ross
/\
\/
|\oss Walker
---------------------------------------------------------
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Adjunct Assistant Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org/ |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Nov 04 2011 - 13:30:05 PDT
