Date: Tue, 04 Jun 2002 13:34:29 -0400 From: The Anarcat <anarcat@anarcat.ath.cx> To: libh@FreeBSD.ORG Cc: Jordan K Hubbard <jkh@queasyweasel.com>, Alexander Langer <alex@big.endian.de>, "anarcat >> The Anarcat" <anarcat@anarcat.ath.cx> Subject: major changes suggestions: features versions and SYSTEM package Message-ID: <3CFCFA25.6060307@anarcat.ath.cx>
next in thread | raw e-mail | index | archive | help
Ok. Here is my final suggestion, please comment and discuss. FEATURE VERSIONNING =================== Features versions SHOULD NOT be mandatory anymore. Each feature will now REQUIRE a serial number *or* a snapshot date. A feature version COULD BE supplied as an advisory number and to ease maintanance. One could compare the serial number to our PORTEPOCH. This will dramatically ease maintenance and feature comparaison. We will avoid the nightmare of the current version scheme [1] which is ridiculously complex and is surely worse than having just an serial number (integer) as version number. ([1]: old pkg version scheme: [0-9]+(\.[0-9]+)*(_[0-9]+)*(,[0-9]+)*, eg. 1.2.4_6,2 , what a mess.) In a worse case scenario, version numbers could be used in a scheme closed as they are now. That is: - the printed form of the feature CAN NOT be a basis for feature comparaison. We have an API, let's use it. - RCS-like version number syntax: 0|([1-9]+)(0|([0-9]+))* (e.g. 0.1 or 1.2.1.3.1, but *not* 1.2_9,1) - version numbers DO NOT have precedence over the serial number. Eg. 1.1 serial 12 > 1.2 serial 0. At worst, a port wishing to rely only on the version to differenciate the features could bump the snapshot date (or the serial number, but that's more ackward) when a new version comes in. This is a bit too error-prone so hooks could be put in place in the ports collection to detect and warn about case where the maintainer tries to do something odd such as 1.1 serial 12 -> 1.2 serial 0, and automatically correct the situation (1.1 serial 12 -> 1.2 serial 12). maintainers wishing to use *only* the version number could then simply set the serial number to 0 and let the version numbers be compared. - snapshot date vs serial number conflicts. As before, serial numbers and snapshot dates can be both specified. Only before we didn't have any explicit way of dealing with this. It is simply a matter of which data is in priority. I would be tempted to suggest that the serial number overrides the snapshot date, but I'm not sure this is really the most intuitive thing to do. I think it would be good to have really the PORTEPOCH "hammer" (ie. all powerful overriding) reflected in the serial number. That gives us an almost backward compatible feature spec and gives us enough flexibility to deal with most cases. SYSTEM PACAKGE SPECIFICATION ============================ SYSTEM will provide the following features (e.g.): Name Version Serial Snapshot Date FreeBSD 4.5 * ** i386 0 0 0 i686 0 *** 0 SYSTEM 0.2.2**** 0 0 * __FreeBSD__ ** branch snapshots *** the serial number could be a bitfield representing CPU options, but that sounds like a very bad idea. **** this is the libh version. A few comments... The SYSTEM package CAN NOT, of course, provide the "libh" feature since it is not libh itself. libh, if installed, will provide this feature, since not all systems will require libh to be installed. But by synching itself with libh's version, the SYSTEM feature will give an idea of its capabilities to consumers. This scheme merges the OSVERSION and OSNAME features, and is a lot cleaner, I think. I will start implementing this shortly if no opposition arises. Roadmap: 1- sweep the documentation and convert the current scheme to the new one using in part this email 2- comment the code and place strategic #warnings where things should be changed 3- full implementation of package versions and SYSTEM package 4- roll a new libh release, we'll be long due. :) 2 and 3 don't exclude modifying the API. I'll put this on the web shortly. A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CFCFA25.6060307>