On Thu, Mar 10, 2011, Jason Swails wrote:
> I think this is actually fairly straightforward:
FWIW, I think Jason has it exactly right here (in describing what the various
branches should contain.) Further comments are given below.
>
> AmberTools and Amber have different bug fixes. The amber11-with-patches
> tracks AmberTools 1.4 and Amber11, so all patches to those two packages are
> applied to amber11-with-patches. The only thing of interest in the
> at15-with-patches branch (being the only thing actually released) is
> AmberTools 1.5, so any patch made for that AT1.5 should be applied to that
> branch.
>
> I think you can generate a howto that details how to create a bug fix based
> on the idea that *some* branch in the git tree will be properly tracking the
> version you're trying to patch. This protocol will be independent of the
> actual branch that you should patch against. Separately we can have a list
> of branches that should be used for patches for different programs.
>
> For instance:
>
> amber11-with-patches: Amber11 & AmberTools 1.4
Right now, amber11-with-patches is tracking both amber11 and at1.4 patches.
After the at1.5 release, only amber-side patches will go here, (because
we will ask amber11 users to upgrade to at1.5.)
> at15-with-patches: AmberTools 1.5
> amber12-with-patches: Amber12 & AmberTools 1.6/2.0(?) (in the future, of
> course)
We can decide on this later. I recognize that there is some desire to more
cleanly separate Amber and AmberTools. If that happens, what goes into various
branches will change.
Of course, one good alternative would be not to have any deficiencies in the
code that need patching.
...dac
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Mar 10 2011 - 11:00:07 PST
