The idea of third party packages is that you can install them
independently of the core.
So when you upgrade Felix,
the packages should continue to work in particular
you may need to hand configure packages and it is really
horrible having to edit the configuration every time a
new Felix core install clobbers it.;
Of course packages themselves may need to be upgraded because
(a) new core felix isn't compatible with them
(b) the underlying C/C++ package has been upgraded
Most packages of most package managers have versioning.
On Linux a crude method:
major.minor.patch
is often used. This means:
* changes in patch fix bugs and don't require recompilation
dynamic loading, no changes needed at all
static linkage, programs need to be relinked
* changes in minor
generally the same as patch
significant changes in algorithms
only upgrades to interfaces
* major
interface changes
Although this is great for major components like gcc, it's useless for packages
without a LOT of human intervention by packagers (to see what works with what
and then specify it).
What I am thinking instead is this: I have already changed Felix to use
YY.MM.DD
Every change when you install Felix you get:
/usr/local/lib/felix/felix-YY.MM.DD/*
/usr/local/lib/felix/felix-latest # symbolic link
I think packages should do the same. Only I am now thinking of a
slightly different scheme. Instead of putting the version number in
the package .. get rid of it!
When you install, the version number is simply the install (or build) date!
When changes are made to packages a history is kept in a known place.
It says things like:
11.07.20: Version 1.0.5
11.04.03: fixed silly bug
By consulting the history, the build date can be translated to the packages
internal "version".
My original idea for packages was that you only had one copy.
Similar to a Linux package manager. For things like Python
separate versions have separate packages, i.e. if it matters
the version number becomes part of the package (and packages
depending on it have to be upgraded just to use the new package)
However there's a more complex option: shadow directories.
We install packages like Felix: into a directory with the install
date and a link to the latest one.
The difference is, we search all the history for components.
I call this "shadow directories". For example if you want to use
the gnu/gmp binding package, you start looking in
packages/packages-latest
and if it's not there try in
packages/packages-YY.MM.DD
for all the directories you have in "packages".
There is an even better way to manage the sources.....
Just use git. The main problem is that this doesn't handle
configuration.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
