h3. Milestone-uri semnificative

Milestone-urile din infoarena2 au fost foarte foarte confusing. Am impartit tichetele vag dupa prioritati, si le-am pus in milestone-uri, dar nu ne-am tinut de treaba. Cu cat un tichet era mai naspa si infricosator cu atat l-am pus undeva in viitor. Daca nimeni nu isi asuma responsabilitatea pentru un tichet atunci acel tichet nu va fi facut, indiferent de milestone-ul in care e pus.
Propun sa avem 2 tipuri de milestone-uri:

h3. Folosim branch-uri

* Time-based, care incrementeaza versiunea cu _0.0.1_. Acolo punem tichete pentru care stim ca avem oameni sa le faca intr-un interval de timp relativ scurt. Le vom sincroniza aproximativ cu sedintele asociatiei sau cu rundele preoni.
* Feature-based, care incrementeaza versiunea cu _0.1_. Acolo punem tichete majore, care merita o incrementare a versiunii. Cand gasim oameni mutam tichetele in +_0.0.1_. Cand ramanem fara tichete intr-un astfel de milestone ii facem release.
 
Pentru noi nu are sens sa mentinem branch-uri stabile si instabile, pentru ca avem o singura instanta care este in productie la orice moment. Site-ul live o sa-l rulam direct din svn de pe branch-ul ultimului release; spre exemplu din _branches/infoarena3-3.2.7_. Daca apare un bug urgent il putem rezolva direct pe live cu commit in acel branch. *NU* vom rula din _tags/infoarena3-3.2.7_, care trebuie sa ramana read-only.
 
Asta presupunem ca folosim layout-ul oarecum standard din subversion; care este discutabil pentru cazul nostru. O idee alternativa ar fi sa tinem branches doar pentru modificari mari si urate, trunk pentru ultima versiune si niste directoare release/infoarena3-A.B.C de unde rulam trunk-ul.
 
Pentru infoarena3 primul release public va fi 3.0. Putem denumi versiunile intermediare ca infoarean3-0.1

Nu mai rupem trunk-ul, toata lumea face brach. Dam lejer acces la svn, dar dam in cap daca face prostii in trunk.

h3. Cum alegem tehnologie