[Gelistirici] version.py hackish

Ekin Meroğlu ekin at fisek.com.tr
3 Haz 2006 Cmt 17:22:53 EEST


Barış Metin yazmış:

>Cumartesi 3 Haziran 2006 16:13 tarihinde, Ekin Meroğlu şunları yazmıştı: 
>  
>
>>--------------------
>><Update release="3"> // svn snaphot, > 0.8.0
>>    <Date>2006-06-01</Date>
>>    <Version>20060805</Version>
>>    bla bla..
>><Update release="2"> // releale, > 20050404
>>    <Date>2006-05-31</Date>
>>    <Version>0.0.8</Version>
>>    bla bla..
>><Update release="1">
>>    <Date>2006-05-10</Date>
>>    <Version>20050404</Version>
>>    bla bla..
>>-----------------
>>madwifi'i bir sonaraki update'imde boyle olacak mesela
>>    
>>
>
>Böyle bir şey hiç bir zaman olmamalı. Çağlar'ın verdiği örnekteki de 
>olmamalıydı, kafamıza göre sürüm numaraları vermeden önce sormamız 
>gerekiyor "ne yapacağız" diye. Version bilgisinin nasıl hesaplanabilecek 
>olduğu (belgeyi veya kodu okumamış olsak bile) rahatlıkla tahmin edilebilecek 
>bir şey. Hatayı hissettiğiniz durumda lütfen sorun ve doğru bir yöntem 
>bulmaya çalışalım. 
>  
>
kafamizdan boyle uydurduk, aynen yaptik gibi yazmisim, haklisin hic bir 
zaman boyle olmamali..

Ama takip ettigim icin bildigim madwifi paketinden ornek verdim :
Madwifi gelistiricileri, proje boyunca iki ay oncesine kadar hic release 
cikarmamisti, svn snapshotsurumu olarak tarih'i kullaniyorlardi, biz de 
oyle basladik. İki ay once gelistirici listesi birbirine girdi, bir 
anda  0.9.0 relelase'i cikti, bir hafta gibi bir sure icinde 0.9.1 
cikacagi konusuldu, biz gectik 0.9.x surum numaralarina.. O gunden 
beridir de 0.9.1'e kadar yapmayi dusundukleri degisikliklerin en az bi 
uc katini yaptilar, hala 0.9.1 yok ortalikta : guncel bir bugfix'e 
ihtiyacimiz olursa yine  svn snapshot kullanmamiz gerekecek. Tabii ki 
artik kolay, Ismail'in onerdigi gibi 0.9.0_20060601 gibi kullanabiliriz 
artik , nispeten de cozmus olacagiz.

Ama durumu boyle abartarak anlatmamdaki neden, maalesef her proje zaman 
zaman  surum takvimi, surum numarasi belirleme gibi konularda garip 
seyler yapabilir, bunun gibi durumlarla karsilasabiliriz demekti, "biz 
verdik numaralari pisi cozsun kardesim" demek istemedim :-)

>Biz bir dağıtımız ve öncelikle kendi içimizde tutarlılığa ulaşmamız gerekiyor. 
>Gerekiyorsa ilgili yazılımın kendi sürümlendirme politikasını görmezden 
>gelerek tutarlı bir sürüm numarasını kendimiz vermeliyiz.
>  
>
Bundan sonrasi icin bir kural belirleyelim ve tutarli hale getirelim, 
kurali da dokumante edelim.
Su anda koda ve dokumana ulasamiyorum, dolayisiyla emin degilim teknik 
olarak ama, Ismail'in soyledigi version_DATE kullanimi  

0.9.0 < 0.9.0_20060601 < 0.9.1

sorunumuzu cozuyor degil mi  ?
Henuz hic surum no *veremediklerimize* de 0.0_YYYYAAGG gibi birsey 
yapabiliriz.

>Örneğin, yukarıdaki örnekte sürüm numarasını hiç bir şekilde büyükten küçüğe 
>doğru bir yöntem ile sıraya sokamayız (evet ben de hayal ediyorum bazı şeyler 
>ama mantıklı hiç bir yöntem diyeyim ;). Diğer taglara da bakamayız... 
>Version, release ve tarihten bağımsız bir değer. Paketin 1. relase'inde 0.3 
>sürümünü kullanırken 2. relase'inde geriye dönüp 0.2 sürümünü kullanmak son 
>derece kabul edilir bir durum.
>  
>
Ama ben yazmistim bana bile mantiksiz geldi diye :)

>Dolayısı ile tutarlı sürüm numaraları vermeliyiz paketler için arkadaşlar :). 
>Hatalı olan sürüm numaralarını düzeltelim. Çağlar, hangi paketler bunlar?
>
>iyi çalışmalar,
>
ekin.



Gelistirici mesaj listesiyle ilgili daha fazla bilgi