On 6/4/02 3:59 PM, Steve Simmons wrote: >> : 1c. Distinctions like "alpha", "beta", and "stable" need to be made >> : according to some convention (a la $VERSION...perhaps $STATUS?) >> >> Can probably burn that bridge when we get to it. > > Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state. > An author could make a package available that was in that condition, > but it shouldn't be uploaded to 6PAN. Once one has that restrition, > $STATUS isn't really needed. The adventurous will upload the alpha > code from the author and install it into the 6PAN tree by specifying some > sort of `force' flag. Thereafter, our adventurere is on his own.
Nah, I think it's useful to be able to upload "unstable" versions to 6PAN to get the widest possible audience of testers. It's a lot easier than hosting it on a web site or whatever--for both the developer and the users. Obviously the 6PAN shell would install "latest stable" by default, but interested parties could get a glimpse of the future if they wanted, and with no harm done to existing code. Also think about the ramp-up to the first stable release. Users may want to try out all the pre-stable versions because they're better than nothing, even if they understand that there I no "API contract" until the first stable release. > On Tue, Jun 04, 2002 at 11:13:53AM -0700, Austin Hastings wrote: >> The following examples of font names are derived from the screen fonts >> shipped with the X Consortium distribution. >> >> Charter 12 pt ... >> -Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-IO8859-1 >> Charter Bold 12 pt ... >> -Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1 >> Charter Bold Italic 12 pt ... >> -Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1 >> Charter Italic 12 pt ... >> -Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1 > . . . > > I was about to run screaming from the room until reading the item a bit > closer. No no, you should still run screaming :) > My current understanding (my hope) is that just saying > > use foo; > > always gets you the latest foo. With (potentially) many modules having > the same name and multiple authors/versions, the current complexity of > the perl /lib tree could increase to the third power. That gonna be > very disk-intensive for every frigging perl script that runs. See my earlier framework/bundle suggestion. I don't think it's that bad, disck-access-wise. > The current perl module tree is pretty difficult for the average day to > day scripter to comprehend. I'd go even further and say that it's so > complex as to be unmanagable. Encapsulating by module would make the structure pretty easy to understand, IMO. > In re putting everything for a given module into a given directory -- > it's a good thought, but I foresee problems with shared libraries > (.so files). With a gigantic module like the Tk:: core, you don't always > want multiple copies of each shared lib for each Tk:: version. It just > ain't gonna fly. Disk space and RAM are cheap and getting cheaper. Think about what you mean by "gigantic." Anyone who exhausts memory by running 150 different versions of the Tk module at once deserves what they get ;) > On the other hand, there's no reason that shared libs couldn't be stored in a > standard location and symlinked to. Yes there is: sanity! I think that's a foolish optimization. It makes things much too fragile. Stuff like that already drives me nuts in regular Unix OS/app installations. -John
