Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Byla vydána verze 1.12 systému pro správu a verzování zdrojových kódů Apache Subversion (Wikipedie). Přehled novinek v poznámkách k vydání.
Tiskni Sdílej:
Jak už tu padlo, ne na "jiný DVCS", protože subversion není DVCS.
Řekl bych, že existují dva typické důvody, proč projekty stále ještě používají subversion:
Pokud "oprávnění" znamenají to, kdo smí co měnit, tak to se i s gitem zařídit snadno dá. Pokud byste chtěl, aby uživatel část repozitáře nemohl ani vidět, pak se spíš nabízí otázka, jestli je opravdu rozumné to mít jako jeden repozitář. Ona mi celá ta vaše konstrukce vůbec připadá spíš jako typický use case na submodules.
Další důvod je, že nás nic moc neomezuje
To bude spíš ten hlavní důvod, i s ohledem na
a kde ano, jdeme cestou oddělení dílčích subprojektů spravovaných přes git se synchronizací do master SVN.
To zní ještě víc jako submodules.
svn update
na celé working copy a vím, že mám všechny projekty které mě zajímají aktuální.
Těch subprojektů, co by musely být jako submoduly, je u jednoho z repozitářů několik desítek za rok. V současnosti stačí založit adresář ve správném místě v existující struktuře a případně upravit nastavení práv, což zvládne kdokoliv. GUI zároveň poskytuje přehledný katalog všech existujících projektů pro výběr co chci klonovat a co ne.
Uvažovali jsme o gitlabu, který na některé věci už dlouho používáme, ale byla by to dost velká změna paradigmatu, pro uživatele víc práce, a jiný přínos skoro žádný. Musel by založit projekt v gitlabu, přidat ho jako submodul do hlavního projektu, ... k tomu hlavnímu projektu by muselo být nějaké lepší GUI pro výběr, které submoduly mě zajímají a které ne.