This is a good question. relax version 1.3.0 was released as a fully
functional version of the 1.3 line prior to the carnage of the data
model redesign (which is now in full swing). This redesign will have
repercussions throughout the relax code base - as can be seen with the
current head revision of the 1.3 line where all of relax is now
broken. No major new features will now go into the 1.2 line. So the
question is where is the best location to branch from to add a new
feature into functional code?
This is difficult question to answer. The redesign will be the future
of the relax code base and hence the changes will need to take this
into account. A branch from the 1.3 line at the revision when the
'tags/1.3.0' repository copy was made could be the best option. The
feature could be developed there in complete isolation from the rest
of relax. Once complete and functional all of the 1.3 line changes
could be merged into the line. I'm 100% sure that this will fail
though. So the changes or 'patch' (the sum of all the changes in diff
format) will probably need to be hand ported to the 1.3 head revision.
The reason for these ideas is that I might take a while to do the
full redesign (help might speed things up though ;).
Is this along the lines of what you were thinking Gary? Ideally new
features would be added to relax after the redesign, but that's not
how open source works. If you want to work with functional code and
don't mind the difficulties of porting an isolated work to a
completely different code base, then this is probably the best option.
However you can do absolutely anything you like in a private branch
as the changes won't touch the 1.2, 1.3, or future 1.4 lines (until it
works, everyone is happy with the changes, and it is ready to merge).
Cheers,
Edward
P.S. As for the ordering, the redesign document
'docs/data_model_redesign' describes what will happen. For any other
features to add to the 1.3 line, there is no order. The only reason
the redesign is occurring directly in the 1.3 line and not a branch is
because these changes will be impossible to merge - they are way too
extensive and touch everything.
On 3/14/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
Dear Ed
The 1.3 branch currently contains a substantial amount of code that
runs but is not in 1.2 should we be thinking of producing a usable
release (1.3.0 or even 1.2.5) with the current feature set before we go
into the long haul of breaking it for the new datamodel etc?
I have to declare a interets as well I am at last going to do some
mutiprocessor work (more code less talk) and i need something that will
actually run to work against (I will make the design so the datamodel
specific stuff is well isolated).
Also what is the current ordering of the changes that are being made
(i.e. what major revisions will be made first datamodel or something else)
regards
gary
--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024
email: garyt@xxxxxxxxxxxxxxx Fax +44-113-2331407
-------------------------------------------------------------------
_______________________________________________
relax (http://nmr-relax.com)
This is the relax-devel mailing list
relax-devel@xxxxxxx
To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel
Re: should the be a relax 1.3.0 or 1.2.5