<[EMAIL PROTECTED]> scria la data de 14 Decembrie 2005: > On Wed, 14 Dec 2005, Liviu Daia wrote: > > > Intr-un proiect serios versiunile declarate stabile sunt > > suportate cel putin cativa ani, iar caile de upgrade _si_ de > > downgrade sunt documentate in detaliu. Schimbarile incompatibile > > in interfata cu utilizatorul sunt anuntate cu cel putin un an > > inainte. Timp de un an functioneaza ambele variante; timp de inca > > un an varianta veche scrie warning-uri dar continua sa functioneze; > > de-abia dupa asta e eliminata. In acelasi regim intra si interfata > > cu alte programe. In plus aceasta e documentata de-abia in momentul > > in care este stabila, iar din momentul in care a fost documentata nu > > se mai poate schimba. Evident, as putea continua. > > Funny. Poti sa ne dai si exemple de proiecte serioase in afara de > postfix ?
Ce incercam eu sa spun era ca poti avea un proiect care se dezvolta rapid si substantial fara sa-ti obligi user-ii sa faca upgrade-uri din doua in doua saptamani doar pentru ca pe tine te chinuie creativitatea. Iar asta nu tine de resurse, ci de management-ul proiectului si de mentalitatea (si poate de experienta) developer-ilor. Am dat exemplul Postfix pentru ca il cunosc bine, si pentru ca mi se pare ca ilustreaza perfect aceasta idee. Personal nu stiu absolut nimic despre proiectul Yate (de la care a pornit discutia), si nu as putea comenta nimic despre el sau despre ce se intampla acolo. Insa afirmatia "toate programele care au nevoie de compatibilitate se schimba mai des de 6 luni" mi s-a parut deplasata. lonely wolf <[EMAIL PROTECTED]> scria la data de 15 Decembrie 2005: > plecind de la ipoteza ca ai intrebat fiindca vrei sa stii, nu doar ca > sa te afli in treaba: > aalib. alsa. at. bind. cups. db. dhcp. dialog. dosfstools. e2fsprogs. > elfutils. exim. flex. gcc. glibc. httpd. iproute. lynx. m4. modutils. > openoffice. samba. sed. sendmail. tar. vim. De acord, dar cu cateva obiectii. :-) (1) Sleepycat db este departe de a fi un proiect stabil in sensul de mai sus. Problema acolo este ca au facut atat de multe schimbari incompatibile de API, incat toate distributiile recente de Linux vin cu cate 3-4 versiuni de libdb instalate. Si cum sub Linux bibliotecile NSS sunt link-ate cu db, rezultatul este incarnarea sub UNIX a "DLL hell" de sub Windows. (2) Cam acelasi lucru este valabil si pentru gcc, de data asta din cauza incodarii simbolurilor C++ in fisierele obiect (v-ati pus vreodata intrebarea de ce programe ca Opera vin in cate 5-6 versiuni numai pentru a suporta diferentele dintre distributiile de Linux?). In sfarsit, o parte din problema are direct legatura cu modul cum e definit limbajul in standarde si cu relatia acestuia cu STL-ul, dar evolutia pare sa fie in rau. (3) Despre problemele din Glibc (a caror aparitie a coincis cu preluarea conducerii proiectului de catre Ulrich Drepper, acum vreo 10 ani) as putea scrie o carte. :-) Voi spune aici doar ca sistemele care nu sunt bazate pe Glibc sunt, in experienta mea, mai eficiente... Evolutia aici pare insa sa fie spre bine. (4) Flex-ul a avut si el cateva momente de ratacire in care a schimbat interfata dupa 20 de ani, insa si-a revenit rapid. (5) In sfarsit, multa lume continua sa nu fie de acord cu multe din schimbarile din Apache 2.x, insa acolo branch-ul 1.x este suportat, si probabil va ramane asa inca multa vreme. > iti dau si exemple de chestii INSTABILE: autoconf. gaim. selinux. [...] Salutari, Liviu Daia -- Dr. Liviu Daia http://www.imar.ro/~daia _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug