Re: [cclib-devel] Refactoring

[Noel O'B. <bao...@gm...>]

I'm going to make a U-turn now. I'm slowly realising that even with
the magic help of svnmerge.py, it will not be possible to cleanly
merge trunk to the release branch (or at least without a lot of effort
hand fixing conflicts and so on), and leave out the refactoring
changes soon after 479.

With this in mind, could we just base the release on trunk (i.e. I'll
merge all of the change to release), and then I'll remove any items in
development (e.g. ccenergies).

Noel

On 09/02/07, Noel O'Boyle <bao...@gm...> wrote:
> cclib 0.7 release branch created based on trunk revision 479.
> Development should still occur on the trunk (or the parser refactoring
> branch). I'll look after merging stable changes to the release branch
> every so often.
>
> Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
> final Jaguar tests.
>
> Noel
>
> On 02/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > > Sounds like this is starting to turn into a major refactoring, and I'm
> > > a bit wary of having this on the trunk, especially as it will be
> > > experimental for the first while. Can you put this on a branch instead
> > > and just test with a single parser for the moment?
> >
> > Karol, it does sound like you are doing some interesting work, but I
> > agree with Noel that this should be developed someplace other than
> > where our current changes are. Especially since my most recent
> > version of PyMOlyze uses trunk as that's where the CDA and
> > FragmentAnalysis code is.
> >
> > What are the current features we are hoping to have in cclib 0.7? If
> > there aren't going to be many changes (esp to parsers), I think it
> > makes sense to merge trunk (from before the refactoring) into a
> > cclib-0.7 branch. If we decide we like the refactoring changes, we
> > can merge those into cclib-0.7 once its stable. What do y'all think?
> >
> > Adam
> >
> >
> >
>