On Thu, Nov 3, 2011 at 2:22 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> Hi Jason,
>
> This is good BUT I think we ultimately need better versioning that this.
> For
> example the GPU code I have v1.0 (AMBER 10), V2.0 AMBER 11 release, V2.1
> AMBER 11 bugfix8 and V2.2 AMBER 11 bugfix17. I think we need to come up
> with
> a better AND consistent way of versioning ALL of our code.
>
Agreed. That's why I put in the commit file where to access the VERSION
variable and how to change it. You'll have to wrap it in a couple ifdefs
if you want different messages printed for different conditional builds,
but I think this is critical! I agree that we need better versioning. The
way I see it happening is that *each* program has up to 2 versions (here I
call pmemd and pmemd.cuda different *programs*) one with the Amber or
AmberTools release number (we can add a patch level which is dead useful,
although I'll address that below) as well as an optional program-specific
version number. We can decide on a format later, but something like this:
sander: Version 11.17 (Amber 11)
pmemd.cuda: Version 2.2 (Amber 11)
pmemd: Version 11.17 (Amber11)
That way we know the patch level/program version as well as the Amber
distribution it came from without going on a hunting expedition. Note that
the way I did this patch, it grabs the program name from arg[0], so the
*only* thing that has to be changed is VERSION in the appropriate place.
Versioning is not difficult coding, and immensely simplifies support and
adds to Amber's clarity (which I think it's lacking right now). So please
let's have a push for everyone maintaining a package in Amber or AmberTools
right now to put a version flag in their programs (I've done so with
mine). I like the idea of it responding to --version and -V, which is
fairly standard amongst many Linux programs out there.
I also think we should be consistent across everything. Thus everything
> released as AMBER 12 - an I still maintain that AMBER 12 should be a
> complete package and we break out the free sections for download later
> (call
> them AMBERLite or AMBERTools)
I think this approach is mostly viable with a consistent versioning
protocol. For staggered releases (which I think are a *good* idea for
encouraging fast-paced development and promoting citations), we will have 2
PBSAs, 2 NABs, 2 cpptraj's, etc., and we need a nice easy way of
determining which is which (output should also contain the version number,
as a couple programs currently do).
> - Thus everything should be V12.0.000 at the
> point of release. Then any bugfixes should increment this. Although I'm
> still not sure the best way to do this.
Here's the downside of this. If this happens, bugfixes *must* _all_ be
applied, in order, to avoid rejecting the chunks that update the version
string. If we adopt this approach (which I still think is the appropriate
approach to take), we will need a more strict bug fix protocol (any bugfix
to a program, no matter how small, should increment the version number of
the associated package), and we'll have to monitor the submitted bug fixes
to make sure they live up to the requirements.
This last part shouldn't be too bad, though, with the tracked bugfix
branches (these have to be enforced!) and the git notification emails (I
admit bugfix commits are few enough that I look at each of them just out of
curiosity).
However, we'll need a smart bug fix application protocol (better than what
we have right now). I'm thinking something written in Python (or perl,
just something more functional than csh/sh) that will manually download the
necessary files from our website and apply them. I'll see if I can find a
small bit of time to whip up a proof-of-principle prototype script to
demonstrate.
> Perhaps we just have V12.DATE where
>
I don't like this idea (not saying it's the one you're championing). I
think the patch level should be present (of the last patch that was applied
specifically to that program). That way, we would know instantly if
someone applied "bugfix.8" because their --version output would return
11.10 or something (which means up to bugfix.10 was applied). That's
mostly what we want to know when people report problems on the list anyway
-- "have you applied bugfix.10?". It would greatly simplify this process.
date is the date of the latest bugfix. - I think this should be distribution
> wide though. With the AMBER and AMBERTools merged together as AMBER 12 -
> Then we only need one bugfix tree. WOW!!!, what a novel idea... The script
> for applying the bugfixes, like the compilation scripts can be made smart
> and it can detect if your tree contains a FULL AMBER 12 or an AMBERLite 12.
>
Yes, which IMO supports a "real" update script, released as part of Amber
12 that will automatically perform updates (and hey, we can have it check
to see if there are unapplied updates available by checking the web -- this
would do worlds to enhance user friendliness!).
Thoughts?
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Nov 03 2011 - 13:00:05 PDT
