Practici de lansare a software-ului - HOWTO

Există o întreagă serie de tradiţii de practici general acceptate pentru codurile open-source care ajută alte persoane să porteze, folosească şi coopereze la dezvoltarea acestora. Unele dintre aceste convenţii sunt tradiţionale în lumea Unix-ului şi există dinaintea Linux-ului; altele au fost dezvoltate recent în răspuns la anumite unelte şi tehnologii, cum ar fi World Wide Web.

Acest document vă va ajuta să învăţaţi practicile general acceptate. El este organizat în secţiuni pe teme, fiecare conţinând o serie de paşi de urmat (checklist items). Puteţi interpreta aceşti paşi ca o listă ce trebuie bifată înainte de un zbor, însă aplicabilă patch-ului sau software-ului d-voastră.

Acest document va fi publicat lunar la grupurile de ştiri comp.os.linux.answers. Puteţi de asemenea vedea ultima versiune a acestui HOWTO pe Internet la adresa URL http://www.linuxdoc.org/LDP/HOWTO/Software-Release-Practice.html.

Sunteţi binevenit să trimiteţi întrebări şi comentarii despre acest HOWTO lui Eric S. Raymond, <esr@snark.thyrsus.com>.

Dacă schimbarea d-voastră include un fişier nou ce nu exista în cod, atunci bineînţeles că trebuie să trimiteţi întregul fişier. Dar dacă modificaţi un fişier care deja există, nu trimiteţi întregul fişier. Trimiteţi în schimb un diff; mai exact, trimiteţi ieşirea comenzii diff(1), rulate să compare versiunea de bază distribuită cu versiunea d-voastră modificată.

Comanda diff şi perechea sa, patch(1), care aplică automat un diff la un fişier de bază, sunt cele mai elementare utilitare în dezvoltarea de software open-source. Diff-urile sunt preferate în locul fişierelor întregi pentru că dezvoltatorul căruia îi trimiteţi patch-ul ar fi putut schimba deja versiunea de bază de când aţi obţinut d-voastră o copie. Trimiţându-i un diff îi salvaţi efortul de a separa schimbările sale de schimbările d-voastră; îi arătaţi astfel respect pentru timpul său.

Este atât contraproductiv cât şi nepoliticos să trimiteţi unui administrator (maintainer) patch-uri relativ la cod aşa cum era acesta în urmă cu câteva versiuni şi să vă aşteptaţi ca acesta să facă toată treaba de a determina care schimbări reproduc lucruri deja schimbate şi care sunt într-adevăr noutăţi în patch-ul d-voastră.

Ca cel care trimite patch-uri, este responsabilitatea d-voastră să urmăriţi starea codului sursă şi să trimiteţi administratorului un patch minimal care exprimă ceea ce aţi făcut d-voastră cu codul de bază. Aceasta înseamnă să trimiteţi un patch relativ la versiunea curentă.

Înainte de a trimite un patch, uitaţi-vă prin el şi ştergeţi orice porţiuni care se referă la fişiere care vor fi regenerate automat odată ce patch-ul este aplicat şi make este rulat. Exemple clasice de acest gen sunt fişierele C generate de Bison™ şi Flex™.

Mai nou, cea mai des întâlnită greşeală de acest gen este trimiterea unui diff cu o porţiune imensă ce nu conţine decât schimbări între scriptul d-voastră configure şi cel original. Acest fişier este generat de autoconf.

Acest comportament denotă lipsă de respect. Înseamnă că destinatarul patch-ului este pus în situaţia dificilă de a separa conţinutul real al patch-ului de o grămadă de gunoi. Este o eroare minoră, nu atât de importantă ca unele dintre cele ce vor urma, dar va conta împotriva d-voastră.

Unii dezvoltatori folosesc anumite cuvinte-cheie (tokens) în fişierele sursă care sunt expandate de sistemul de control al versiunilor când fişierul este introdus în sistem (checked in): de exemplu secţiunea $Id: Software-Release-Practice-HOWTO.ro.html,v 1.2 2004/05/13 21:20:35 buzdugan Exp $, folosit de RCS şi CVS.

Dacă folosiţi un sistem de control al versiunilor local, schimbările d-voastră ar putea altera aceste cuvinte cheie. Aceasta nu este prea rău pentru că atunci când cel căruia îi trimiteţi patch-ul va introduce codul înapoi în sistemul de control după ce a aplicat patch-ul d-voastră, cuvintele-cheie vor fi re-expandate pe baza stării propriului său sistem de control al versiunilor.

Dar acele porţiuni suplimentare din patch sunt gunoi. Crează doar confuzie. Este mai respectuos să nu le includeţi în patch.

Aceasta este o altă greşeală minoră. Veţi fi probabil iertat dacă rezolvaţi cu bine problemele principale pe care le adresează patch-ul d-voastră. Dar este mai bine să o evitaţi.

Formatul implicit (-e) folosit de diff(1) este foarte fragil/instabil. Acesta nu include nicic un context, astfel că utilitarul patch nu poate lucra dacă au fost introduse sau şterse linii în codul de bază de când aţi luat d-voastră copia pe care aţi modificat-o.

Este supărător să primeşti un diff -e şi sugerează că cel ce a trimis patch-ul este fie foarte nou, fie neglijent, fie n-are idee ce face. Cele mai multe dintre patch-urile de genul acesta sunt de obicei ignorate.

Acest lucru este foarte important. Dacă patch-ul d-voastră crează ceva adiţional vizibil-utilizatorului sau schimbă capabilităţile software-ului, includeţi schimbări în paginile man corespunzătoare şi în alte fişiere de documentăţie în patch-ul d-voastră. Nu presupuneţi că destinatarul patch-ului va fi fericit să documenteze codul în locul d-voastră sau să aibă capabilităţi nedocumentate ascunse prin cod.

Documentând schimbările pe care le faceţi dovediţi unele lucruri bune. În primul rând, arătaţi respect persoanei pe care încercaţi să o convingeţi. În al doilea rând, arătaţi că înţelegeţi ramificaţiile schimbărilor d-voastră suficient de bine pentru a le explica cuiva care nu poate vedea codul. În al treilea rând, demonstrează că vă pasă de cei care în fapt vor folosi respectivul software.

O documentaţie bună este de obicei cel mai vizibil semn ce separă o contribuţie solidă de o contribuţie făcută în grabă şi de mântuială (quick and dirty). Dacă alocaţi timpul şi atenţia necesară pentru a produce patch-ul, veţi observa că sunteţi 85% pe cale să aveţi patch-ul acceptat de cei mai mulţi dezvoltatori.

Patch-ul d-voastră ar trebui să includă o notă care să explice de ce credeţi că patch-ul este necesar sau folositor. Această explicaţie nu este destinată utilizatorilor software-ului ci administratorului căruia îi trimiteţi patch-ul.

Nota poate fi scurtă -- de fapt, unele dintre cele mai efective note pe care le-am văzut spuneau doar "Vezi documentaţia actualizată de acest patch". Dar nota trebuie să evidenţieze o atitudine corespunzătoare.

O atitudine corespunzătoare este ajutătoare şi respectuoasă faţă de timpul administratorului, încrezătoare, dar cu moderaţie. Este bine să arătaţi că înţelegeţi codul pe care îl modificaţi în patch. Este bine să arătaţi că vă puteţi identifica cu problemele administratorului. Este de asemeni bine să preveniţi despre orice risc presupus de aplicarea patch-ului. Iată câteva exemple din genul comentariilor ce explică schimbările şi pe care îmi place să le văd în notele trimise:

“Am văzut două probleme în acest cod, X şi Y. Am reparat problema X, dar n-am încercat să mă ocup de Y pentru că nu înţeleg acea parte de cod în care cred că apare.”

“Am reparat un ``core dump'' care poate avea loc când una dintre intrări e prea lungă. Şi dacă tot m-am apucat, am căutat depăşiri de memorie (overflow) similare şi în alte părţi. Am mai găsit una potenţială în blarg.c, pe la linia 666. Sunteţi sigur că expeditorul nu poate genera mai mult de 80 de caractere pe transmisie?”

“V-aţi gândit să folosiţi algoritmul Foonly pentru această problemă? Există o implementare bună la <http://www.somesite.com/~jsmith/foonly.html>.”

“Acest patch rezolvă problema acută, dar realizez că pe de altă parte complică alocarea memoriei într-un mod neplăcut. Merge OK pentru mine, dar probabil că ar trebui testată în condiţii de încărcare maximă înainte de a o distribui.”

“Aceasta ar părea capabiliturită, dar o trimit oricum. Poate că veţi avea o metodă mai curată de a implementa această capabilitate.”

De obicei, ca administrator, voi dori să am încredere deplină că înţeleg schimbările d-voastră înainte de a le aplica. Aceasta nu e o regulă invariabilă; dacă aveţi o istorie de patch-uri bune pe care mi le-aţi trimis anterior, s-ar putea să arunc doar o privire pe schimbări înainte de a le aplica (check-in) semi-automatic. Dar orice puteţi face pentru a mă ajuta să înţeleg codul d-voastră şi să-mi scadă incertitudinea vă creşte şansele de a vă accepta patch-ul trimis.

Comentariile bune din cod mă ajută să-l înţeleg. Cele proaste nu.

Iată un exemplu de comentariu prost:

/* norman începătorul a făcut această corectură pe 13 Aug 2001 */

Acesta nu transmite nici o informaţie. Nu e nimic altceva decât un marcaj teritorial pe care îl plantaţi în codul meu. Dacă voi accepta patch-ul (ceea ce a devenit mult mai puţin probabil), e aproape sigur că voi elimina acest comentariu. Dacă doriţi credit pentru schimbările făcute, includeţi o secţiune în patch pentru fişierele NEWS sau HISTORY. Probabil că voi accepta acea secţiune.

Iată un exemplu de comentariu bun:

/*
 * Acest condiţional trebuie să fie protejat pentru a nu trimite
 * un pointer NULL lui crunch_data()  <norman_newbie@foosite.com>
 */

Acest comentariu arată că înţelegeţi nu numai codul meu, ci şi genul de informaţii de care am nevoie pentru a avea încredere în schimbările d-voastră. Acest gen de comentariu îmi dă încredere în schimbările d-voastră.

Este mai uşor pentru toată lumea dacă toate fişierele d-voastră arhivă au numele în stilul GNU, adică folosesc numai litere mici în prefixul trunchi (stem), urmat de o liniuţă, urmat de un număr de versiune, extensie şi alte sufixe.

Să presupunem că aceţi un proiect pe care l-aţi numit 'foobar' aflat la versiunea 1, release-ul 2, nivelul 3. Dacă aveţi o singură arhivă (de exemplu codul sursă), iată cum ar trebui să arate numele:

Vă rugăm nu folosiţi aceste nume:

Dacă trebuie să diferenţiaţi între arhivele sursă şi binare, sau între diferitele tipuri de binare, sau să exprimaţi un oarecare tip de opţiune de construire în numele fişierului, vă rugăm să trataţi aceasta ca o extensie de fisier ce merge după numărul versiunii. Adică, folosiţi această metodă:

Vă rugăm nu folosiţi nume ca 'foobar-ELF-1.2.3.tar.gz', pentru că e dificil pentru programe să separe infixe (cum ar fi '-ELF' de trunchi (stem).

O formă generală bună de nume are aceste părţi în ordine:

Unele proiecte şi comunităţi au convenţii bine definite pentru nume şi numere de versiuni care nu sunt în mod necesar compatibile cu recomandările anterioare. De exemplu, modulele Apache sunt în general numite mod_foo şi au atât propriul lor număr de versiune cât şi versiunea de Apache pentru care sunt destinate. Similar, modulele Perl au numere de versiuni ce pot fi tratate ca numere în virgulă mobilă (de exemplu, aţi putea vedea 1.303 în loc de 1.3.3), iar distribuţile sunt în general numite Foo-Bar-1.303.tar.gz pentru versiunea 1.303 a modelului Foo::Bar. (Pe de altă parte, Perl a trecut la folosirea convenţiilor descrise în acest document pe la sfârşitul anului 1999.)

Uitaţi-vă după şi respectaţi convenţiile comunităţilor specializate şi dezvoltatorilor; pentru uz general folosiţi instrucţiunile din secţiunea anterioară.

Prefixul trunchi ar trebui să fie comun tuturor fişierelor arhivă ale proiectului şi ar trebui să fie uşor de citit, tastat şi amintit. Aşa că nu folosiţi caractere underscore ('_'). Şi nu capitalizaţi sau BiCapitalizaţi fără a avea un motiv extrem de bun -- deoarece strică ordinea de căutare a ochiului uman şi pare mai mult o încercare de a părea deştept din partea unui comis-voiajor insistent şi iritant. Oamenii sunt derutaţi când două proiecte diferite au acelaşi nume.

Aşadar încercaţi să găsiţi eventuale conflicte înainte de a lansa proiectul. Există două locuri bune în care puteţi verifica şi anume fişierul index la Metalab şi appindex la Freshmeat. Un alt loc bun în care puteţi încerca este SourceForge; căutaţi şi acolo.

Orice software ce nu este domeniu public are un copyright, posibil mai mult decât unul. Conform Convenţiei de la Berna (care a fost legea în SUA din 1978), copyright-ul nu trebuie să fie explicit. Aceasta înseamnă că autorii unei lucrări deţin copyright-ul chiar dacă nu există nici o notă de copyright.

Cine contează ca autor poate fi foarte complicat, în special pentru software-ul la care au lucrat mai multe persoane. Acesta este motivul pentru care licenţele sunt importante. Stabilind termenii sub care fiecare material poate fi folosit, licenţele acordă drepturi utilizatorilor care îi protejează de acţiuni arbitrare din partea deţinătorilor de copyright.

În cazul software-ului proprietar, termenii licenţei sunt proiectaţi să protejeze copyright-ul. Aceştia reprezintă o cale de a acorda câteva drepturi utilizatorilor dar păstrând cât mai mult teritoriu legal pentru proprietar (deţinătorul copyright-ului). Deţinătorul copyright-ului este foarte important şi logica licenţei este atât de restrictivă încât termenii tehnici exacţi ai licenţei sunt de obicei neimportanţi.

În software-ul open-source, situaţia este de obicei contrară; copyright-ul există pentru a proteja licenţa. Singurul drept pe care deţinătorul copyright-ului îl păstrează întotdeauna este acela de a impure respectarea condiţiilor licenţei. Astfel, numai câteva drepturi sunt rezervate şi cele mai multe alegeri sunt pasate utilizatorului. În particular, deţinătorul copyright-ului nu poate schimba termenii unei copii pe care o aveţi deja. Prin urmare, în cazul software-ului open-source, deţinătorul copyright-ului este aproape irelevant -- dar termenii licenţei sunt foarte importanţi.

În mod normal deţinătorul copyright-ului unui proiect este liderul curent al proiectului sau organizaţia ce sponsorizează proiectul. Transferul proiectului către un nou lider este adesea semnalat prin schimbarea deţinătorului copyright-ului. Totuşi, aceasta nu este o regulă general acceptată; multe proiecte open-source au multipli deţinători de copyright şi nu există nici o antecedenţă care să indice că aceasta a condus la probleme de ordin legal.

Unele proiecte aleg să desemneze Free Software Foundation (Fundaţia pentru Software Liber) ca deţinătoarea copyright-ului, în ideea că acesta are un interes în apărarea proiectelor open-source şi avocaţi disponibili să facă acest lucru.

Din punct de vedere al licenţelor, putem distinge câteva tipuri diferite de drepturi pe care o licenţă le poate acorda/transmite. Drepturile de copiere şi redistribuire, drepturile de folosire, drepturile de modificare pentru uz personal şi drepturile de redistribuire a copiilor modificate. O licenţă poate să restricţioneze sau ataşeze condiţii oricărora dintre aceste drepturi.

Organizaţia Open Source Initiative (Iniţiativa Open Source) este rezultatul unor eforturi uriaşe de a defini ceea ce face software-ul ``open-source'' sau (într-o terminologie mai veche) ``free''. Constrângerile acesteia referitoare la licenţiere cer ca:

Regulile de ghidare interzic punerea de restricţii pe redistribuirea de binare modificate; această cerinţă satisface nevoile distribuitorilor de software, care trebuie să poată livra cod în stare de funcţionare fără restricţii. Aceasta permite autorilor să ceară ca sursele modificate să fie redistribuite în stare nemodificată plus patch-uri, prin urmare stabilind intenţiile autorului şi o ``cale de verificare'' a oricăror schimbări făcute de alţii.

OSD-ul este definiţia legală a mărcii de certificare `OSI Certified Open Source' (certificat de OSI ca open source) şi este cea mai bună definiţie de ``software liber'' care a fost prezentată/dezvoltată vreodată de cineva. Toate licenţele standard (MIT, BSD, Artistic şi GPL/LGPL) satisfac această definiţie (deşi unele, cum ar fi GPL, au restricţii pe care ar trebui să le înţelegeţi înainte de a le alege).

De notat că licenţele care permit folosirea doar pentru scopuri non-comerciale nu se califică drept licenţe open-source, chiar dacă sunt decorate cu ``GPL'' sau alte licenţe standard. Acestea discriminează împotriva anumitor ocupaţii, persoane şi grupuri. Acestea fac viaţa distribuitorilor de CD-ROM-uri şi a celorlalţi care încearcă să răspândească software-ul open-source comercial prea complicată.

În unele cazuri, dacă aveţi în spate o organizaţie ce vă sponsorizează cu avocaţi, aţi putea dori să acordaţi copyright-ul acelei organizaţii.

Open Source Definition este standardul de aur al comunităţii pentru licenţe. OSD nu este o licenţă în sine; mai degrabă aceasta defineşte un set minim de drepturi pe care o licenţă trebuie să le garanteze pentru a fi considerată open-source. OSD şi materialele de suport pot fi găsite pe website-ul Open Source Initiative.

Bine cunoscutele licenţe conforme cu OSD au deja tradiţii de interpretare bine stabilite. Dezvoltatorii (şi, în măsura în care le pasă, utilizatorii) ştiu ce implică acestea şi şi-au format o părere rezonabilă cu privire la riscurile şi compromisurile pe care le implică. Prin urmare, dacă se poate, folosiţi una dintre licenţele standard pe care le găsiţi la site-ul OSI.

Dacă trebuie să scrieţi propria d-voastră licenţă, încercaţi să o certificaţi de OSI. Aceasta va evita o grămadă de certuri/lupte şi eforturi suplimentare. În afară de cazul în care aţi trecut prin aceasta, e puţin probabil să realizaţi cât de aprinsă poate deveni o discuţie pe tema licenţelor; oamenii devin pătimaşi deoarece licenţele sunt considerate ca înţelegeri/acorduri aproape sfinte atingând valorile fundamentale ale comunităţii open source.

Mai mult, existenţa unei tradiţii de interpretare bine stabilite se poate dovedi importantă dacă licenţa d-voastră va fi vreodată contestată în instanţă. În momentul în care a fost scris acest document (începutul anului 2002) nu există nici o lege care să suporte sau să invalideze orice licenţă open-source. Totuşi, există o doctrină legală (cel puţin în SUA şi probabil în alte ţări cu legi similare cum ar fi Anglia şi restul Commonwealth-ului britanic) care spune că instanţele trebuie să interpreteze licenţele şi contractele în conformitate cu aşteptările şi practicile comunităţii în care a apărut.

Pentru portabilitate şi stabilitate, ar trebui să scrieţi cod fie în ANSI C, fie într-un limbaj de scripting care este portabil garantat pentru că are o singură implementare pentru toate platformele.

Limbaje de scripting care se califică includ Python, Perl, Emacs Lisp şi PHP. Shell-urile tradiţionale nu se califică, există prea multe implementări diferite cu particularităţi subtile, iar mediul shell este potenţial subiect de poluare datorită modificărilor făcute de utilizatori, de exemplu prin folosirea a alias-urile.

Java promite să fie un limbaj portabil, dar implementările disponibile pe Linux sunt încă instabile şi nu prea bine integrate cu Linux. Java este încă o alegere avantgardistă, deşi promite să devină mai populară pe măsură ce se maturizează.

Nu vă bazaţi pe limbaje proprietare, biblioteci sau coduri similare. În comunitatea open-source aceste acţiuni sunt considerate total nepotrivite. Dezvoltatorii open-source nu au încredere în produse cărora nu le pot vedea codul sursă.

Dacă scrieţi cod C, puteţi folosi cu încredere întregul set de capabilităţi ANSI -- inclusiv prototipuri de funcţii, care că vor ajuta să descoperiţi inconsistenţe între module. Compilatoarele pentru vechiul stil K&R sunt depăşite şi irelevante. Pe de altă parte, nu presupuneţi că anumite capabilităţi specifice pentru GCC cum ar fi opţiunea '-pipe' sau funcţii încuibărite sunt disponibile. Acestea se vor întoarce împotriva d-voastră şi veţi regreta că le-aţi folosit de îndată ce cineva portează codul d-voastră pentru un sistem non-Linux, non GCC.

Dacă scrieţi cod C, folosiţi autoconf/automake/autoheader pentru a soluţiona chestiunile legate de portabilitate, efectuaţi probe pentru configurarea sistemului şi ajustaţi makefile-urile d-voastră. Cei ce-şi construiesc programele singuri se aşteaptă să poată tasta "configure; make" şi să obţină o construire curată -- şi pe bună dreptate.

Dacă scrieţi cod C, compilaţi ca test cu opţiunea -Wall şi curăţaţi erorile cel puţin o dată, înainte de a lansa fiecare nouă versiune. Aceasta prinde un număr surprinzător de erori. Pentru o verificare şi mai amănunţită folosiţi şi opţiunea -pedantic.

Pentru proiecte Python, programul PyChecker poate fi folosit cu succes pentru verificări. Acesta este încă în stadiul beta, dar cu toate acestea prinde o mulţime de erori non-triviale.

Dacă scrieţi cod Perl, verificaţi codul d-voastră cu Perl -c (sau poate -T, dacă e cazul). Folosiţi perl -w şi 'use strict' cu regularitate. (Vedeţi documentaţia Perl pentru discuţii legate de această temă.)

Rulaţi un program de verificare a ortografiei pentru aceste fişiere. Dacă arătaţi că nu puteţi scrie corect şi nici nu vă pasă, oamenii vor deduce că şi codul d-voastră e plin de greşeli şi deci neutilizabil.

Cea mai supărătoare greşeală făcută de dezvoltatorii începători este să creeze arhive tar care despachetează fişierele şi directoarele distribuţiei în directorul curent, schimbând potenţial fişiere deja existente acolo. Nu faceţi niciodată acest lucru!

În schimb, asiguraţi-vă că toate fişierele din arhiva d-voastră au o parte de director comună numită după proiect şi că acestea vor fi despachetate într-un singur director top-level, imediat sub directorul curent.

Iată un truc cu makefile care realizează acest lucru, presupunând că directorul distribuţiei d-voastră e numit `foobar' şi SRC conţine o listă a fişierelor ce trebuie distribuite.

foobar-$(VERS).tar.gz:
	@ls $(SRC) | sed s:^:foobar-$(VERS)/: >MANIFEST
	@(cd ..; ln -s foobar foobar-$(VERS))
	(cd ..; tar -czvf foobar/foobar-$(VERS).tar.gz `cat foobar/MANIFEST`)
	@(cd ..; rm foobar-$(VERS))

Aveţi un fişier README sau READ.ME care conţine o descriere succintă a distribuţiei d-voastră. Convenţional, acesta este primul fişier pe care cei mai cutezători îl vor citi imediat după despachetarea surselor.

Este recomandat ca fişierul README să includă:

Înainte chiar de a fi citit README, exploratorul cutezător va fi scanat deja numele fişierelor din directorul top-level al distribuţiei d-voastră despachetate. Acele nume pot ele însele transmite informaţie.

Iată câteva nume de fişiere standard din top-level şi ceea ce înseamnă. Nu orice distribuţie are nevoie de toate acestea.

De notat convenţia generală ca numele fişierelor ce furnizează meta-informaţie despre proiect să fie scrise cu majuscule şi nu componente de construire (TAGS este o excepţie la prima, dar nu la a doua).

Având un FAQ vă poate salva o grămadă de probleme. Când o întrebare despre proiect reapare frecvent, puneţi-o în FAQ împreună cu răspunsul; apoi dirijaţi utilizatorii să citească FAQ-ul înainte de a trimite întrebări şi rapoarte despre bug-uri. Un document FAQ bine îngrijit poate reduce povara de suport de pe umerii administratorilor proiectului cu un ordin de mărime sau chiar mai mult.

Având un fişier HISTORY sau NEWS cu datele la care au fost lansate fiecare dintre versiunile proiectului este extrem de util. Printre altele, acesta poate stabili criteriul de 'prior art' (creaţie anterioară) dacă veţi fi implicat vreodată într-un proces de încălcare a patentelor (aceasta nu s-a întâmplat încă nimănui, dar mai bine să fiţi pregătit).

Software-ul d-voastră se va schimba în timp, pe măsură ce lansaţi noi versiuni. Unele dintre aceste schimbări nu vor fi compatibile cu versiunile anterioare. Prin urmare ar trebui să vă gândiţi serios să proiectaţi modelul de instalare astfel ca pe acelaşi sistem să poată coexista multiple versiuni ale codului d-voastră.

Proiectele Emacs, Python şi Qt au pus la punct o procedură convenabilă şi practică pentru a rezolva această problemă; directoare numerotate cu numărul versiunii. Iată cum arată ierarhia unei biblioteci Qt instalate (${ver} este numărul versiunii):

/usr/lib/qt
/usr/lib/qt-${ver}
/usr/lib/qt-${ver}/bin          # Where you find moc
/usr/lib/qt-${ver}/lib          # Where you find .so
/usr/lib/qt-${ver}/include      # Where you find header files

Cu această organizare puteţi avea multiple versiuni ce coexistă fără probleme. Programele client trebuie să specifice ce versiune de bibliotecă doresc să folosească, dar acesta este un preţ mic de plătit pentru a nu trebui să schimbaţi interfeţele pentru ele.

Formatul standard de fapt pentru instalarea pachetelor binare este cel folosit de managerul de pachete Red Hat, RPM. Acesta este folosit de cele mai multe dintre distribuţiile Linux populare şi în fapt este suportat de toate celelalte distribuţii (cu excepţia lui Debian şi Slackware; iar Debian poate instala din RPM-uri).

Prin urmare este o idee bună ca site-ul proiectului d-voastră să ofere RPM-uri instalabile, precum şi arhive tar cu codul sursă.

O altă idee bună ar fi să includeţi fişierul RPM spec în arhiva tar cu codul sursă, iar Makefile-ul d-voastră să conţină o regulă de producţie (target) ce crează RPM-uri din el. Fişierul spec ar trebui să aibă extensia `.spec'; acesta este modul în care opţiunea rpm -t o găseşte în arhiva tar.

Pentru puncte suplimentare, generaţi fişierul d-voastră spec cu un script shell care introduce automat numărul versiunii analizând fişierul Makefile sau version.h.

Notă: Dacă furnizaţi RPM-uri cu cod sursă, folosiţi opţiunea BuildRoot pentru a construi/crea programul în /tmp sau /var/tmp. În caz contrar, la rularea comenzii 'make install' în timpul procesului build, install va instala fişierele în locurile reale de destinaţie. Aceasta se va întâmpla chiar dacă există coliziuni de fişiere şi chiar dacă nu aţi dorit să instalaţi pachetul. Când aţi terminat, fişierele vor fi fost instalate şi baza de date RPM a sistemului d-voastră nu va şti nimic de ele. SRPM-uri cu asemenea comportament sunt un teren minat şi ar trebui evitate!

Prezentăm aici formatele de marcare (markup) pentru documentaţie care au în prezent o largă răspândire pentru dezvoltatorii de open-source. Când vorbim de marcaje pentru "prezentare" ne referim la marcaje care controlează aspectul documentului în mod explicit (cum ar fi o schimbare de font). Când vorbim de marcaje "structurale" ne referim la marcaje care descriu structura logică a documentului (cum ar fi o pauză după o secţiune, etc.). Iar când vorbim de "indexare" ne referim la procesul de extragere dintr-o colecţie de documente a unei colecţii căutabile de pointeri către subiecte pe care le pot folosi utilizatorii pentru a găsi în mod fiabil material de interes din întreaga colecţie de documente.

În luna iulie 2000, reprezentanţii unor grupuri de la proiecte open-source importante (incluzând GNOME, KDE, Free Software Foundation, Linux Documentation Project şi Open Source Initiative) au participat la o întâlnire-conferinţă în Monterey, California. Scopul întâlnirii a fost să se încerce stabilirea unor practici comune şi formate comune de inter-schimbare a documentaţiei, astfel încât să poată evolua un corp de documentaţie mult mai bogat şi mai unificat.

Concret, ţelul avut în vedere este un tip de documentaţie care, atunci când este instalat pe sistem, este integrat imediat într-un index larg de documente aflate pe întreg sistemul într-o asemenea manieră că acestea pot fi navigate printr-o interfaţă uniformă şi căutabilă ca un întreg. Din paşii luaţi deja în această direcţie de GNOME şi KDE era deja evident că aceasta ar necesita un standard de marcaje mai degrabă structural decât pentru prezentare.

Întâlnirea a subscris la o tendinţă ce fusese clară de ceva vreme; proiecte cheie open-source se mişcă către, sau s-au mutat deja, spre DocBook ca format principal pentru documentaţie.

Participanţii au mai decis să aleagă şi formatul de meta-date `Dublin Core' (un standard internaţional dezvoltat de bibliotecari destinat indexării materialului digital) pentru a suporta indexarea documentelor; detalii legate de acest subiect sunt încă în lucru şi probabil vor rezulta în unele adăugiri la marcajul DocBook pentru a suporta incorporarea de meta-date Dublin Core în documentele DocBook.

Direcţia este clară: folosirea pe scară mai largă a formatelor DocBook cu standarde auxiliare care suportă indexarea automată a documentelor DocBook bazată pe marcajele lor de indexare şi pe meta-data Dublin Core. Există încă piese lipsă din această imagine, dar acestea vor fi completate curând. Zilele vechilor formate de marcaje prezentaţionale sunt numărate. (Acest HOWTO a fost mutat în format DocBook în luna august 2000.)

Prin urmare, cei ce încep noi proiecte open-source vor fi "ahead-of-the-curve" şi vor fi scutiţi de o conversie neplăcută mai târziu, dacă pornesc de la început cu DocBook ca formatul principal pentru documentaţie.

Anunţaţi noile lansări/versiuni la comp.os.linux.announce. În afară de faptul că este foarte citit, acest grup este sursă de conţinut pentru website-uri de ştiri cum ar fi Freshmeat.

Găsiţi un grup de discuţii USENET cu subiect relevant aplicaţiei d-voastră şi anunţaţi proiectul şi acolo. Trimiteţi mesaje numai grupurilor relevante respectiv cu funcţia îndeplinită de codul d-voastră şi fiţi reţinut.

Dacă (de exemplu) lansaţi un program scris în Perl care interoghează servere IMAP, cu siguranţă că aţi putea trimite un mesaj la comp.mail.imap. Dar probabil că n-ar trebui să trimiteţi mesaje la comp.lang.perl dacă programul d-voastră nu este un exemplu instructiv folosind tehnici extreme de programare Perl.

Anunţul d-voastră ar trebui să includă URL-ul website-ului proiectului.

Dacă intenţionaţi să construiţi o comunitate substanţială de utilizatori sau dezvoltatori în jurul proiectului d-voastră, acesta ar trebui să aibă un website. Acesta ar trebui să aibă lucruri standard cum ar fi:

Unele proiecte furnizează URL-uri pentru acces anonymous la arborele sursă principal.

Este o practică standard să aveţi o listă de discuţii privată pentru dezvoltare, cu ajutorul căreia cei ce colaborează la proiect pot comunica şi schimba patch-uri. Ar mai putea fi utilă o listă pentru anunţuri pentru cei care doresc să fie informaţi despre evoluţia proiectului.

Dacă numele proiectului d-voastră este `foo', lista de discuţii pentru dezvoltare s-ar putea numi foo-dezv sau foo-prieteni; iar lista de anunţuri ar putea fi foo-anunţuri.

În ultimii ani, arhiva Metalab a fost cea mai importantă locaţie pentru publicarea de software Linux.

De la lansarea sa în 1999, SourceForge a explodat în popularitate. Aceasta nu este doar o arhivă şi loc de distribuţie, deşi poate fi folosită în acest mod. Acesta este un serviciu de găzduire a proiectelor libere care încearcă să ofere un set complet de utilitare pentru grupurile ce dezvoltă open-source - spaţiu de web şi arhivare, liste de discuţii, monitorizarea bug-urilor, depozit (repository) CVS şi alte servicii.

Alte locaţii importante includ: