Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
Zistil som, že vlastne neviem používať git tak, ako by som potreboval Chcem vyrobiť branch a do toho branch-u pridávať len bugfixy zatiaľ čo do master vetvy pôjdu aj bugfixy aj nové feature.
Graficky by to vyzeralo nejako takto:B1<-B2<-B3 B3<-B4 / / ...<-R1<-F1<-F2<-B1<-F3<-B2<-F4<-F5<-R2<-F6<-B3<-B4<-F7...S tým, že:
Nie je správne urobiť merge, pretože tým by sa mi do branch-u dostali aj feature, ktoré som commitol do master. To isté rebase.
Robiť cherrypick, mi nepríde vhodné, pretože jeden bugfix môže pozostávať z viacerých commitov, ktoré možno ani nemusia ísť po sebe.
Tak ako to vlastne robiť správne?
On asi neexistuje jediný „správný“ systém. Když budeš hledat „git workflow“, tak najdeš řadu různých způsobů – každý to dělá trochu jinak.
Já tedy používám primárně Mercurial a následující systém:
v_1
, v_2
atd.v2.0.0
, v2.1.0
(tzn. štítky a větve se poznají i podle názvu – větve mají v názvu podtržítko, štítky ne).v2.1.0
) odkloní nová větev (např. v_2.1
) a v ní se vyvíjí a vydané opravy se označují štítkem typu v2.1.1
, v2.1.2
atd.v_2.1
do v_2
, případně pak do v_2.2
, v_3
, v_3.1
atd. (pokud existují).Tiskni Sdílej: