On 01/02/2015, at 10:56 AM, Ryan Gonzalez wrote: > > By consulting the history, the build date can be translated to the packages > internal "version". > > Is this required for packages, or is it optional? Personally, I like the > major.minor.fix scheme better.
It's just an idea. the major.minor.fix scheme has advantages, and on many Linux (and other Unix) systems, it is enforced by the way links to shared libraries are maintained. The problem is that there is no coherent way to interlink such packages. If packages depend on major.minor, then patches are irrelevant: packages can be upgraded in isolation. With major.minor the assumption is you need the same major (no other will do) but any minor greater or equal to the specified one. It's all a nice idea. But the reality of the world is continuous ad-hoc integration and in that scenario the categorical distinctions of the package numbers are useless UNLESS some human comes along and organises the dependencies. This works with that, this can replace that, etc etc. This is what Debian and Ubuntu and ArchLinux and all the other package managers do and it is a HUGE effort which typically fails most of the time. The last Debian release took over 2 years to get out. Using a date YY.MM.DD defines your whole system with a single number. Packages are comparable by date. They're NOT comparable by major.minor.patch. With Git, "working" versions can probably be tagged. Although I have yet to figure out how to actually tag the repository (the instructions never seem to work for me). There's a related problem: how to store the packages. On Github you say. Well sure, but how? Mike Maul's system used a repository called litterbox, which contained the index to the other repositories. See. at present there are a number of "packages" built into the core, including the new GUI stuff (which depends on SDL bindings). That's easy for me to maintain: make changes to anything, run the test suite, commit. Every now and then do an install for a backup (since I normally run the build image directly). With multiple packages it's much harder. I have to decide where to put them on my computer. I have to cd around doing changes and commits and pushes. And then how do the tests get done? i really HAVE to make the GUI stuff separate because the felix-lang.org server of course won't run SDL (there's no screen, mouse, or keyboard :) Similarly, gnu/gmp has to be separate because it doesn't build on Windows and not everyone will be willing to use GPL libraries. -- 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
