Byla vydána verze 7.0 open source platformy pro správu vlastního cloudu OpenNebula (Wikipedie). Kódový název nové verze je Phoenix. Přehled novinek v poznámkách k vydání v aktualizované dokumentaci.
E-mailový klient Thunderbird byl vydán ve verzi 140.0 ESR „Eclipse“. Jde o vydání s dlouhodobou podporou, shrnující novinky v upozorněních, vzhledu, správě složek a správě účtů. Pozor, nezaměňovat s průběžným vydáním 140.0, které bylo dostupné o týden dříve.
Organizace Video Games Europe reprezentující vydavatele počítačových her publikovala prohlášení k občanské iniciativě Stop Destroying Videogames.
Společnost Raspberry Pi nově nabzí Raspberry Pi Camera Module 3 Sensor Assembly, tj. samostatné senzorové moduly z Raspberry Pi Camera Module 3.
Cathode Ray Dude v novém videu ukazuje autorádio Empeg Car (později Rio Car) z let 1999–2001. Šlo o jeden z prvních přehrávačů MP3 do auta. Běží na něm Linux. Vyrobeno bylo jen asi pět tisíc kusů, ale zůstala kolem nich živá komunita, viz např. web riocar.org.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.7.
Wayland byl vydán ve verzi 1.24.0. Jde o menší vydání po více než roce. Více funkcionality bývá přidáváno v průběžných vydáních Wayland Protocols.
Textový editor Geany byl vydán ve verzi 2.1. Jde o udržovací vydání po bezmála dvou letech. Obsahuje drobná vylepšení vyhledávání, aktualizace podpory zvýrazňování syntaxe a dále převážně opravy chyb.
Byly zveřejněny videozáznamy, dostupné také s prezentacemi přímo z programu, a také fotogalerie z open source komunitní konference DevConf.CZ 2025 konané od 12. do 14. června v Brně.
Navigace se soukromím CoMaps postavena nad OpenStreetMap je nově k dispozici v Google Play, App Store i F-Droid. Jedná se o komunitní fork aplikace Organic Maps.
dobry den,
sme mala developerska firmicka (3 ludia) a robime mobilne aplikacie. ako verzovaci nastroj pouzivame SVN. IDE Eclipse. Pre kazdu zakazku/projekt mame zvlast repozitar.
Dostali sme sa ku vacsiemu projektu ktory bude mat backend (asi tomcat), frontend (web), GUI (client). Client bude mat moznost pouzivat pluginy. Rad by som sa opytal aky zvolit model vyvoja a verzovania?
1) je nacase sa zamysliet nad Gitom?
2) drzat vsetko ako jeden projekt v Eclipse?
3) drzat vsetko v jednom repozitari a zvlast branche pre client/pluginy/web/backend?
4) rozdelit to na jednotlive projekty a mat zvlast repozitare?
dakujem
Čím skôr, tým lepšie. Marš na CZ.NIC a stiahni knihu Pro Git - veľmi Ti pomôže.1) je nacase sa zamysliet nad Gitom?
Nie.2) drzat vsetko ako jeden projekt v Eclipse?
Nie, branče slúžia na niečo úplne iné. Až prejdeš na Git tak to pochopíš. SVN Ti túto vedomosť nemal ako sprostredkovať.3) drzat vsetko v jednom repozitari a zvlast branche pre client/pluginy/web/backend?
Jeden repozitár nie je pre Git problém, ale SVN z toho dostane záhul (moja skúsenosť). Ak ale máš podprojekty, ktoré spolu súvisia len cez API, asi by som ich aj tak oddelil do samostatných repozitárov.4) rozdelit to na jednotlive projekty a mat zvlast repozitare?
Co se myslí tím rozbíjením závislostí při přepínání větví?
Pokud budete mít podprojekty v samostatných repozitářích, bude těžké udržet přehled o tom, který snapshot podprojektu A je kompatibilní s kterým snapshotem podprojektu B. Pro posloupnost klasických release verzí se to ještě asi uhlídat dá, ale třeba při bisectu, kdy potřebujete přeložit a otestovat zcela obecné snapshoty, si to moc představit neumím.
Rozhrani mezi moduly by mělo být neměnné
To je chvályhodné předsevzetí, ale… Pane Smrtko, proč vy se pořád tak usmíváte?
git log --stat
u každého commitu vypíše, jaké soubory se měnily. Psát to do komentáře je zbytečné.
Pokud chci vidět modifikace Makefile, tak stačí zavolat git log Makefile
(případně git blame Makefile
, pokud mě zajímá, kdo tam změnil konkrétní řádek).
Dokumentace není jen ve zdrojáku. Zdroják popisuje API, ale těžko bude popisovat třeba to, jak se daná aplikace instaluje a debuguje, s jakými formáty souborů pracuje či jak jsou zdrojáky organizované.
Takže radši budete mít v gitu polovinu commitů, které nejspíš nepůjdou ani přeložit, natož aby fungovaly? Happy bisecting… Nemluvě o tom, že ani samotné tvrzení, že se bude hůř psát commit message, mi nedává moc smyslu.
Promiňte mi mou upřímnost (a přímost), ale celá druhá část této diskuse na mne působí, jako kdybyste nikdy s žádným netriviálním projektem do kontaktu nepřišel, ale nejsa nezatížen praktickými zkušenostmi, vytyčil jste jakési teoretické zásady a teď na nich lpíte, přestože lidé, kteří praktické zkušenosti mají, se vám snaží vysvětlit, že nejsou moc v souladu s tím, jak takový vývoj v praxi funguje.
Tiskni
Sdílej: