From 6b227e2a6371eb4a54ccf3c40a5b8d9238a62d49 Mon Sep 17 00:00:00 2001 From: kewang Date: Sat, 20 May 2017 18:44:10 +0800 Subject: [PATCH 01/19] Add favicon --- source/assets/images/favicon.ico | Bin 0 -> 128862 bytes source/assets/images/logo.svg | 1 + source/layouts/layout.html.haml | 1 + 3 files changed, 2 insertions(+) create mode 100644 source/assets/images/favicon.ico create mode 100644 source/assets/images/logo.svg diff --git a/source/assets/images/favicon.ico b/source/assets/images/favicon.ico new file mode 100644 index 0000000000000000000000000000000000000000..7a0f5974577f207acb8660f1a5a95b9cb228e473 GIT binary patch literal 128862 zcmeH~F_t5}ZiUrnf(|EhXgPG~9mt_KVQ)p+kj0~^}-5i=EE^>6?A zKi8T6eaoS~nw~a+neXZ-ds@>k@WW4F^xfJ@{=+|rR|Dn=Y~|gX?ZZ5nSHh+zF#COZ zB>tu!)XQ9T0*~~5-OForaIfGdCUCEJ;u-30;sJhh6VLD-ZK;QE{yN>f{VhFv_EHXD zYyLcb%AQ{Lu@mq-laZWQ_kYtyeBCnlZ`ZH8kqOLxZX@1i=FaZh%AeWmv$L(U*7VOX zFRjO0oIk@HZ_z{4v$%!VE!2pbmzA@H-nZ((I?GbO)xK`+tDMWs`&;+6^?D<--gmp{IGa}}h^R~7}`y2I* z*0JhFeWCeQUr~D0pG7z7%~IxTm++H6MXVLwPc#8Jo;i3LLY{@}uv~}4_j&YgE=o&pctDorlH6H4zmaD~3w&*n8=(*JK ztfRF@@;!cQIU^p*+#0_ZEAyl8d$r}vQ&V!$)l);uL2HldG#^ptqdqx5$_sO>ej;n< zEYwGygX~dm^jz7SrS>c>GNTdAsPB>5WvAtE-?UqpRoSUg14MC)4Xp}knSr5>%bWnI}*#J#uQ zh}z7s)Q_l%*0a`{#m#-7H6BHm_ZG4D_8n218J7B^HPKp@Iy0DgeU$&Gy1dtjy=M*) zb(w+I9<7JevD83#tg$e2Ey{leUEcTT-ZPKUnv##!7QJ!FJrCZqNY7Re5w+2p)><>T2-E75^$546 z@zjgVY5DTR@98U|HrlhLRx~r3C%vHDQYZOaT1$`K`>38Q^&@Jc^(?gz<~?~_8}V3b zES~SBEj@egqr6*cN7O{?p|ucRB#Y~zJk}xpN{xlT1#RiydLPw;rS51=v=&k)lEw89 z9^xz4AWYHZd5^f4K0Iqwzn0pgHPKpH9fYGX^7DJ}q-O5p(f87mb&cv9tvgyTst&?I zy&^2uMDr|6wDwkX=uC56g!i1M?MLfrd^zvc5lwIH<>zNThMeVkZ7(_6s&O9uT1TmpQHbJg2vBXG6YOyF5!ikt!t%pa8-Evm9sD;$1JtJ>k z$%^7IHKSH^nza#rS)_oAD%mi1cqX#G}xFOIT%x*lK7 zdiltiaC$4kX=!>~Ig?zu@2#Tkt-X9X>*e#A=z6Qh7(MUR&d-oKxgOmkTvUV9L|HW* z!e>n_7l|Q!;b>aXX=?;WWAM4=WAq&HfcijLq8s&I<_lL_%RI}y#^!SiFV|Ywnl|UQ z_8J52MdP&UN5(Y|a<0`B9lB~f?>SQ6%jUe9e1y#!#0SzNQcvSVFti%TIpRZR*W#fJ z(X}`cajDT;N9y#ra^~ere#DA+KVzIY)f3ro}?@Mc3j)#-&zo9jVvj%9)2R zxe+T;AE~2pA{bf?nu6qy-mSI)eA$sb*j`dW=!F_1c%M(ah+ zOOC|RwalM=kNEO>xHmhhzQ)n!qvi9t#)vvcyp(>>oLm>>7vy z$sb)KYH19_qsE9jN4&5`>Y@5vC%Ly=^ZKp*h@Tcy;$F7okFHvMgntW$Rs%gp`e6<8 zP;IV5eaz71K3aQk-4-v8d)RrtcaPLX*cvB-q18ao5ihJ^9;y``>S2~neDqdt?H*Ik zJZ#AwS&_O3U*l*DEkE*H^Wr^^^ypje+=x(r8|+=TW|*IGTTN9gWN99yY?&G)P^Iq4^)pM?6|I zh#ypAse3Ce;@#^-V|%z76FEofj&erx5swxP;s?=KYTi;i)4Rs@^rxU+t+kqWKKFXk*jBE_6R(;MsjD%hR*N;7-{N}Xh#yVkt$m9;%{!laeQ0be zSL2CSO^4Lg7*ean8qIHUy>Y}3qVd+Boj23F#Y~hnYEucTfEpT$HKlkbX1GpI#Q?-@}gPT6mfk?PruTnveQKbeb1AXO`?OE8=0M2Jz~t zAI-J!G%ecCC}%Vu^@->-FLEv{xwov6dyf_I>G7p;EliEY=Q&T)=i1(Wlrx&&^JYEM zyvTXZm6&DC^KZG=JbJxEay1s8=RU3aJU8EKoLpPmkLK5y-k9b^&P%?;Eo;fR#l7aw z<3VHcxrJ-xS@kV18mE;faV?+EMLT;%ytMqFxw&q3KRG|I+uG-Pbl+m-ag@cnJg>FS zc`Z#I&-JZ+uCMJ|c@nSXlrhoHUdy_z`<9QEz87z?qT@Xea^|TixxE$T_84+jvLxPH z%bePMFQ3n9Ib|$@Q8GREnh!beu|;E9d%UPK#E++z#E}na<$9In>XDCB@&qw;n^~fG!qBDwOAsnPP)@Uq*qcQj#;dnJj{n;M8-pf3smof*r zkK{(NqBz`t1S^7pJd2hFsn42L{+8lMFIK+@(=s1~hkDdlQ5>{C%@4{!edju)_RRXZ zmytcvhld}@jbw2zQM|2jW<4kF)5E@HPSmr=JtIuZY!F^vU)x9WqF7NJt@rXAsmq!& zZ%g+`4<5gfT!dwvGr~msj$%b|P~W0M>as@kTU%%OkLDsg>ue*LQ7nYR8f&kb{$6!8 zU+6jFA7$mbNG`%+OYC? z^Wcr$qo&tuo;TAs!p^<)_6UnLJx1>g;rH_Mv#qjnkF7o8ePqt9x})(~z9YGjtk%4c z8m-(~Jc@^KSX1-xU1GCl6wQt1)t)a>qn6i-Me-09Yg%5OIX-hX2pgR(!isu^NUccU zk*ug0pq{p%L!OsttbQd=TM@3tkaL8EXoS~W5sqkj961xMwu)X`HO{k~YjeoYtv%>(uV8+!~{d&0tCmD|;(? z@o!x{{?Qr;8)dN$;dwNu2Mhb2OsQ@0y9KTIwyqxUXbqGd%|q*!I>bkrqut+&S=QBj z-ut}tYq|G$NBJl_nupe{>1KGD!DR0!H`mpAzIQD5XWe_fTk0S+qIpQoo(A>PW7N*> z%`NNKJl;B1da~Yo{aWfEHKKV)O+7r(sbF`Y)^PFwjTk4=(l!@{pb+f$9;^w`hH4t6Swd@hLM`Q6& zYOVFk{Mx;RSeE_(7Ps_)*4etQ z?8|y@?GNEwmt^Uy(7B0%Xl@9Ul^@6Zjw2ENXC9AeEejiE-b07<;q`^EMdPi3lb>1m`k!WYd* zooC3EIe1pIe+wIBZb66kHR2VmA-a)TkD4pJTUSfJ7Pf`E6)n==s8^&$t{JWODEWEM z*1e_2nQV)XnOd~R5f5mMQa4g_%eiHr)_Y5DGuaj&x6q=!j(9<9)N~_tx0GA!%@VWr zVqvq^%HNtE?RV5STBoHOt$(llRzH@w)w_kwS}T96dbIBd|7fk2F2cht7%l(SxW%iL z&3X&}5wyq*qWVB;A(|*ZQ5?iGsoH(a|;jF z8jqyc<}2q>Jqa&*jq=yxMEez9t6ncIxt6uZdxo=n&B9XGtMxt~Z#_$%$D4(pYdy6d zF(>c2x1Z5luii7Bd1vUEg}2rt=b>|&)gxN}k#*kLd3yHNdWJl7UNd_|Jv@@mJ1=jK z-g?iHXPMjVo-JOss2!b;x2Ms%&ysJM-z|E!_}PMXbS5J`jMjd(e9J6v*}KKpEwvFd z81WlX|5+K9x!z+27JoCekv)(2i}dk~EYEE3IR}qlOU{hmEcI*J8J?bzS(}{}+u|HF z&vJe%?^4gZ-pc1Q)p^Z2?rC~wndim1`F^B)j+XuRn^e7H%gkEZI{6i~PM|ekByO$s z40>cPsOA~wv9%u1+1GSi>t%+YTHoH-41X`?*95%JCC~e!J^n85D{BAvQ+bRIzWeiv z>c8YX#?yZ;m*q1Uz2EwDM*HjKZ@u^L;IH?5yk}dOo7cM~Zwr0CJbX>S^6b3YuWIo- zuP1L_dKkN94qo=4{L%6;4kpzp_)b&os!m-87D*z&ttdYjSzi}{=rDBqoX z-aqGrUtQg60<+)cd-e6*>t2_O#<1?va$fJwJf7p%$r}I7;XGrFUs8DY{+Y1E|19C% z?jQ$C{FlUk{2gC0bSepp{v`U(3MroO|Gb>7pcH491V~x?&uXfaBDn zJQ%9Vx#Z8I_XhFj?CtpT8KD%q`RT#bY7;uQy6r z9suDEbVI%={_%tC(3UQ;#RUjP@yk1TBP3sG{AWsD;uoGAU+IZn$Oy&HKd-Dv7gatI z?YPEI3!aXa!Uv9@_E)a9)Hu`j4^`v%fj6Y&9zNI^ol$&u_?@7s+23rEupB?~B&ek{ zm>utb&@GLPI%Z62>P)$pCC(i$&zH_WsLID1=?Ri1krLQEKcyv3lenZX#r}{Pl9Ha1 z*jKvPZuQY?$%#jL`{+-IFSNeM8=gF@V$1fD;4*5!Dh;@0V_)m({MACJl^OMB6 zJ!*)r3!C{#gJJ#Baf)*t(s2CDamr2CZz_6uzy9L*o;v17$QM6Rp6;8(k13oUEkBJl z&ae7%oqwkHHO0BJHJsr59uw#A@lKW3iy{2ppLeIf<8KsPPkq`uW{N@JbfxDPO87+ z)K=0<{B&6K+}4#^p%m7WuQkr^;@|ND@prp@BTlE+Uw?5ZLi%GFr_MP}VS070G_AGn z5>F4g5>F3viPLjopNqZ~&p3bSr7rdRcl@~c`G4_)#QA;us+;COe)yBM#LuLpzIbj~ z{Cr69w>0NUJUthV@A-2TpT=-`oJl4{LnC#M67r52c7x)oXf54j=S=^7Vd}@ynhjNPZ-~JM#C>=}4cKulSi> z^5ccRulVywCPaVU)0aXcPMs}!YF_mGUAo3U(&v4xd!p~s^!-WS4|$w^J?H~Y-^2X9 zK|>c#`t{(re9tT#f|H1PrSG@p`{y%GUqMU!*AG&y9D=7W=H+|uD^6MIi&^5wRi9pm z^!t*&SLvg&@CknYN!#^%cz0Oi7k<27aryu(dWxU+oV0w;pZ00^^tD0n_~9!~x64HW zek`O<-?pFe9gm;xIKC*7o_<`|7pN_G-lTGxBvRPLmvY6MMak1!2{i=i@vgw zZjJBx$BZv})jw#8$0g41z#+wV^r?7Hzj({mfl(( z569DAH0iT-y%27KSmBRx%r4e!!*px>UE@Et#$Q%a>cJph^- zH$y$kn~~xNZkEFI(DwXy9bFth?WqCo=0XoMeJQT-K M5)Qw)Uv%dGAFK55u>b%7 literal 0 HcmV?d00001 diff --git a/source/assets/images/logo.svg b/source/assets/images/logo.svg new file mode 100644 index 0000000..4bc1b76 --- /dev/null +++ b/source/assets/images/logo.svg @@ -0,0 +1 @@ +Artboard 1 \ No newline at end of file diff --git a/source/layouts/layout.html.haml b/source/layouts/layout.html.haml index ab2526d..4e82b73 100644 --- a/source/layouts/layout.html.haml +++ b/source/layouts/layout.html.haml @@ -17,6 +17,7 @@ -# Icons + %link{rel: "shortcut icon", type: "image/x-icon", href: image_path("favicon.ico")} %link{rel: 'canonical', href: path_to_url(current_page.url)} %title= current_page.data.title From f2567b0036c84609c82df1ed89e7bbaba3f6a1f4 Mon Sep 17 00:00:00 2001 From: kewang Date: Sat, 20 May 2017 18:59:17 +0800 Subject: [PATCH 02/19] Add og:image --- source/assets/images/logo.png | Bin 0 -> 4263 bytes source/layouts/layout.html.haml | 1 + 2 files changed, 1 insertion(+) create mode 100644 source/assets/images/logo.png diff --git a/source/assets/images/logo.png b/source/assets/images/logo.png new file mode 100644 index 0000000000000000000000000000000000000000..ec0efe8e464cd59362fc13a422356a9fc15bede7 GIT binary patch literal 4263 zcmY*ddpy(M|9`s_y2vKglGxB{lJHS(xvZH@gjW8vA=kwR^cixZpIq&E5bujhHa(=H zi@jtf@pZ@kUD_~2d*V3&kogOXGPMgCnB!kg`m8Twa`_2w>$aLNnO6g?d%Y{fRT(O- zo!4hy#q6Z6iFVi768XAG8xy;QzW#5KX~{XZwlpzW&uD@%wnhYs0}ud!fi)DwcL-Y> z8$+^`aB?yR{!2+!NFa?cLX3)ymH`6*2&z~tzD*(}rGRMikyA>Fs_O_h6h_#ixI7wl zY|-~JRAt+ZZX6!-nLn`$h^{pAAQo2Trz^jWr2qh#6H`2-BVvw~f{Fk#DX}UqY+v(N zc>4ih0_CCdJ)h#_Wg!I-nn0q+|Gc`}P)#PWadqOrkrObLZ5P!lzlN~6aQA*e{bp1KX^iMj*FL&}2#B z_FzKdwi%7WUEm~%GHoy_ zb}&&uJ9HKSHEtqp1jWQAa(eQJ#wC|T0KN1OIh%den-11OqJS@lK&`oZ^(HP- z<(OvMYkex4a#Bif#kwAX1fMeqaC@x^1MU=<*NZ0m*$?YMxyPfPI;_1o2;6zF+(|G8 zmv>&AJhs8X>%cpJOyOqMi$9P(_PyhKnH0_(eBPUo1p-X6$sQ^SR^ysTn>jlV;hUAZ zkl|=GUwVuSg2aW?5^&Q43jxb)1^@wQCpiq=kFnhvz#6F6% zM7UNe9A-an^^G)pH@7)zBjcdh37?T?`s9uY- z^jkr$uKfoss|=Z|J=8fBPrGF4@<3$o=vyZyMV#nwj}<(_UzNW7)FnosG(I@ zv^6Mh*A(~sPyOIF$V4&)#JJI8f#H=$GL)8gd{NH7d~kkKyw@9G5BA`jcCP)Jn_+ZD z&a~;cK0hiImqy9jeS`Hb*?@6hzs2FMUaK_1_8Sj7asDSEL;0o&$M<2sk6c4L=0W)3 zuHh_sC$kLoE6;`*u0hEuU9#=U10C5~#a!}i=5fN^d}D?t-B+2V%o1S94d1X885B9e zX__yHwKs}A%>B0$@qWZ|1-18RziI9{d9AS%s!M;e`+Gb4!Xj5Uv@$0Q)rYB{X+bV4 zb{lOARfp&}smDhX>_Fews93XKk%DCj~*X^%BADg@m~L2`;ba$yZ|eLDl^oZsu(~)U zBd>m5j3k8d*c&($>5rd+#UV9bwB!nDRH5lD@2%KWye5Bu0pV;_83+4^1 zzcb1*l>#~PzgqUQN9SibHzAtVDH_0WWf;rzYfI5oaDJDbre+!lK&f~~JB7aF=eIFF zBspjx(ZHiTas}oGzbEHzmUkIU`QzVxK8fJ^XBXDhhl7Xy^7fFK3HUNZ_dGXu?FD@$ zvQ|N@{&DSj(&%3Dmm1g?RzaiH^tBXiWrA5i+8md7*Q%%1^JlSM>g4yua0=2k+FVKn| zZ(A{VH_OvXli_~3g??1o=K~9W@`S!tVbnfJogqGKGpNyBuXPxI=&tA-?)hA+J;Q&l zY%NJY7{T1Qb3pwdo%!Ri)hcWL{sTJW?VpN4?DqJ-}LkrQf7 zU8ngUP(`&6-%LuLw@a-*9OV+QR;JEyS?G*1KxDAYPFRG|jShWR*3B}Jjyje-EBBO#k{k!?683kA5bgyy68#mdL{{rQI}xL-5>O` z;_y9-Z^kG?J;YJtHlvvml|QM^jh}6Z_ODAsspfXg5X0@Cxm_p1A)2dhv6FrZ zqBHZ48S*#lCMrm$3JHg4RJG|wyCak6g?lyfgJj8R)duPHc)R|h;`YA;3%wOj38gom z6Vhuh6gJv0I99c$C?qG$qDN#kEcNW007BIF&&k0Gfr%xYCvPX&;O^{ZG+PWHOV+(9 zvaS42L7@6EnIhxl zz0XZdD2q-3Fley^P@P4_IIUwOn?;1t9Fz-(x`YeWP*O^-p|V0&1b~f7Wyb=*>3^B> z*?BN674eS(046F1t!vgZir(y&@gckOA!?@vZGqConA6i6H`j7fhH z613tYJUirPE19FKB;R%3c8vl>H!kVfBwGkJI+rR>U9DXjQjdBNur-{)8?0F;E$Hv` zs9O(2kD`nrart{S2Lr6~ancP1R86*T(L`u%hcW#<-(jsjylPb9O!@A3*=2L9Lw z)gUhX*ea?9rC82#sa;%RKIvsv&1t$5Yx)om*N-hlZWIk_78cB^KvR0@`{BvFy`ys0 z9cSVr)yE=vhsZ>WSL`7H#HvhTRBx$)K6Zk+N4v^d-SWz;GIMYyjvAh5=g6*^Q7cUp zslM5LlvFa>nC#53HJBf=Vnzm+Zq{}DP2lfj$;I_WH(B))Q$X5)4eM`eC@y zi1Tr2Y9l$*{)uf68aS^Z1%mU(R3gwGII+1NXwarhw?hqyZo%POoxXl# z`VZSp-vkwLChRDL1?{_vq~r_{7Xr6PTZ^mp#=Lh=b|ttQyl)MBx|Ah0snO&omYSc6DNRR;SyajfG&Dnkl2R0WT|bLo4?D zE{hM<>ZHnO@8~V~G5=?SU)r1!V75s>xzQq%@wXk$fTQHre^8^Yp3sQ+i*0+o2X0_F zK+@}3c&0_F4?nwpVxcH1M_s8%;D`I;4EfQZ(q-?NXz_#oUf^f&-6d|)cGM%M zGq@wZ1#T|Tj*70-Qr1+%RSmsoH^IAlEq;_5m2u15R~ug1`!AL4_h5;w{snP_La95m zXku9b*F9YopLaUD6`$9mC#^_xf0k#0=@Mpea)D;j zV|1hZ-0fu982?FNK?!>1v{y@# z;&c#_1+`RAMNNvgoc{3TvW|ncky)joffn7@S+)4LuVj~KoJkK3%r2n*bPDBVDf#j5C?9{W=nASLL*dhc2*W`Ui_TH#?}{fY-j{VzQqNoVY&x zkMz3EzZr`)G+2u56;|r?*z`Y<{Qlnj=L&0iOF;uFm2Z@uA`|xxg&X}!;_eRytxA(r z*%6R^KHAgEFKixLDnt-M4L-A9m*=yCs{1vG6G3kZdikFJeBqq=DXw@h%KqIbzAa~i zb`J3b-?GH3%dvlF?qO1qD_5Rcp{3t^O1PNG28Lnn#>|3MJ|wiH1H;KRs$(iF482eO zePJRQgfQMi5Y$gj%Y#V-?)p~$ElPG?;;mGi29z7()_)z>;%mM|Ow7~?SqZaWzxZwS z2XAaV>+<6ddBk9m@5i9LooV*|L9eeT>E_rz6t!#Jon?p+x9(Xl>t|?c-9K44%dbla z&gU9wi>pk(AP#NhZ0t*t-p$)LUCyEpXKDZ9}{TBiRZfMr*{-9TKi0Cc0{p5GQASo@2-*@auZuxQ{kf**J+tDcoNRxlF6QHCYFjXK6P^c zCZ|>CI%Z@N#H-w!d-s4#U&6#1j%Bb(A3%FXRela!D4?`r6n|y*_v}=^=3H=O<03w4 z*ciM^a`VS7sW$Jfg$kQ_6SR~q-3;&YU2|@a^{ZhlTJa!Ud#rf25z=+f z<+6pAesF2!sK{se!R0`IEd$G81YY0ZOE9VM^l6dQ#Kbda2GA*KBZ;gkN(eiF z72vn?5EbVu9_|x}^hHH{eE$|p$bDhYD6?d`7(Uell;S;G-}>bRmE4a8fVzVzW#a7f zqfc*XZ_8+U2>lrEW`RuFKHyafjET@3H2gP0DCZcuV~j#wB3x0JJa=Eja3q8|c$_2@ zx{Z+-vJj$#d8+U%0)ieZ788<8RysxcKj^UyyRED-+y5B;e|hD$DKUBh=}mQUTido^ M%`8z>$ZIkG1DBTCp8x;= literal 0 HcmV?d00001 diff --git a/source/layouts/layout.html.haml b/source/layouts/layout.html.haml index 4e82b73..9573e36 100644 --- a/source/layouts/layout.html.haml +++ b/source/layouts/layout.html.haml @@ -13,6 +13,7 @@ %meta{property: 'og:type', content: 'article'} %meta{property: 'og:url', content: path_to_url(current_page.url)} %meta{property: 'og:description', content: current_page.data.description} + %meta{property: 'og:image', content: image_path("logo.png")} = yield_content :og -# Icons From 8be04ff2fb28124f32d8f1cca657cffbd05d2120 Mon Sep 17 00:00:00 2001 From: Artur Weigandt Date: Tue, 20 Jun 2017 17:01:30 +0200 Subject: [PATCH 03/19] German translation for v1.0.0 --- source/de/1.0.0/index.html.haml | 321 ++++++++++++++++++++++++++++++++ 1 file changed, 321 insertions(+) create mode 100644 source/de/1.0.0/index.html.haml diff --git a/source/de/1.0.0/index.html.haml b/source/de/1.0.0/index.html.haml new file mode 100644 index 0000000..aecdd00 --- /dev/null +++ b/source/de/1.0.0/index.html.haml @@ -0,0 +1,321 @@ +--- +description: Keep a Changelog +title: Keep a Changelog +language: de +version: 1.0.0 +--- + +- changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md" +- gemnasium = "https://gemnasium.com/" +- gh = "https://github.com/olivierlacan/keep-a-changelog" +- issues = "https://github.com/olivierlacan/keep-a-changelog/issues" +- semver = "http://semver.org/" +- shields = "http://shields.io/" +- thechangelog = "http://5by5.tv/changelog/127" +- vandamme = "https://github.com/tech-angels/vandamme/" +- iso = "http://www.iso.org/iso/home/standards/iso8601.htm" +- ghr = "https://help.github.com/articles/creating-releases/" + +.header + .title + %h1 Führe ein CHANGELOG + %h2 Lass Deine Freunde nicht CHANGELOGs mit git logs füllen. + + = link_to changelog do + Version + %strong= current_page.metadata[:page][:version] + + %pre.changelog= File.read("CHANGELOG.md") + +.answers + %h3#what + %a.anchor{ href: "#what", aria_hidden: "true" } + Was ist ein Changelog? + + %p + Ein Changelog ist eine Datei, welche eine handgepflegte, chronologisch sortierte + Liste aller erheblichen Änderungen enthält, die zwischen Veröffentlichungen (oder Versionen) + des Projekts umgesetzt wurden. + + %h3#why + %a.anchor{ href: "#why", aria_hidden: "true" } + Was ist der Zweck eines Changelogs? + + %p + Es Benutzern und Entwicklern einfacher zu machen, gerade die beachtenswerten Änderungen, welche + zwischen Veröffentlichungen (oder Versionen) des Projekts gemacht wurden, zu sehen. + + %h3#who + %a.anchor{ href: "#who", aria_hidden: "true" } + Wer braucht schon ein Changelog? + + %p + Menschen brauchen es. Seien es Konsumenten oder Entwickler, der Endnutzer der Software + sind Menschen, die es interessiert, was in der Software ist. Wenn sich die Software ändert, + dann wollen diese Menschen wissen, wie und warum sie sich ändert. + +.good-practices + %h3#how + %a.anchor{ href: "#how", aria_hidden: "true" } + Wie erstelle ich einen guten Changelog? + + %h4#principles + %a.anchor{ href: "#principles", aria_hidden: "true" } + Grundlegende Prinzipien + + %ul + %li + Changelogs werden für Menschen geschrieben, nicht für Maschinen. + %li + Für jede einzelne Version sollte es einen Eintrag geben. + %li + Änderungen des selben Art sollten in Bereiche gruppiert werden. + %li + Versionen und Bereiche sollten sollten verlinkt werden können. + %li + Die neuste Version kommt als erstes. + %li + Das Release-Datum jeder Version muss angegeben sein. + %li + Gibt ab, ob du dich an die #{link_to "Semantische Versionierung", semver} hältst. + + %a.anchor{ href: "#types", aria_hidden: "true" } + %h4#types Arten von Änderungen + + %ul + %li + %code Added + für neue Features. + %li + %code Changed + für Änderungen an der bestehenden Funktionalität. + %li + %code Deprecated + für Features, die in zukünftigen Versionen entfernt werden. + %li + %code Removed + für Deprecated-Features, die in dieser Version entfernt wurden. + %li + %code Fixed + für alle Bug-Fixes. + %li + %code Security + um Benutzer im Fall von geschlossenen Sicherheitslücken zu einer Aktualisierung aufzufordern. + +.effort + + %h3#effort + %a.anchor{ href: "#effort", aria_hidden: "true" } + Wie kann ich den Aufwand der Changelog-Pflege so klein wie möglich halten? + + %p + Habe immer einen Unreleased-Abschnitt über der neusten Version, + um zukünftige Änderungen im Auge zu behalten. + + %p Dies hat zwei Vorteile: + + %ul + %li + Menschen können sehen, welche Änderungen sie mit dem nächsten Release zu erwarten haben. + %li + Wenn der Zeitpunkt für den Release gekommen ist, kannst du den Inhalt des + Unreleased-Abschnitts in den neuen Release-Abschnitt verschieben. + +.bad-practices + %h3#bad-practices + %a.anchor{ href: "#bad-practices", aria_hidden: "true" } + Kann man beim Changelog etwas falsch machen? + + %p Ja. Hier sind einige Dinge, die eher unbrauchbar sind. + + + %h4#log-diffs + %a.anchor{ href: "#log-diffs", aria_hidden: "true" } + Einen Diff von Commit-Logs ausgeben + + %p + Commit-Logs in einem Changelog sind eine schlechte Idee: Sie beinhalten lauter + überflüssige Dinge, wie Merge-Commit, Commits mit schlechten Bezeichnungen, + Änderungen an der Dokumentation, etc. + + %p + Der Sinn eines Commits ist die Entwicklung des Source Code zu dokumentieren. + Manche Projekte haben saubere Commits, andere nicht. + + %p + Der Sinn eines Changelog-Eintrags ist die Dokumentation der merkbaren + Unterschiede, die meist über mehrere Commits hinweg entstanden sind, dem + Endnutzer klar und deutlich zu kommunizieren. + + + %h4#ignoring-deprecations + %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" } + Features ohne Deprecation-Warnung entfernen + + %p + Wenn der Endnutzer auf eine neue Version upgradet, sollte ihm unmissverständlich + klar gemacht werden, wenn etwas kaputt gehen wird. Es sollte immer möglich sein, + zu einer Version zu upgraden, die die zu entfernenden Features auflistet, um so + in seinem Source Code auf diese Features zu verzichten. Anschließend sollte man + auf eine Version upgraden können, in der die Features entfernt wurden. + + %p + Auch wenn du sonst nichts geändert hast, liste trotzdem alle veralteten und + entfernten Features, sowie jede funktionsgefährdende Änderung in deinem Changlog auf. + + + %h4#confusing-dates + %a.anchor{ href: "#confusing-dates", aria_hidden: "true" } + Verwirrende Datumsformate + + %p + In den USA setzen die Menschen den Monat an den Anfang eines Datums + (06-02-2012 für den 2. Juni 2012), wohingegen viele Menschen + im Rest der Welt ein roboterhaft aussehendes 2 June 2012 + schreiben, aber es völlig unterschiedlich aussprechen. 2012-06-02 + folgt der Logik vom größten zum kleinsten Wert, kann nicht mit anderen Formate + verwechselt werden und ist ein #{link_to "ISO Standard", iso}. Deshalb + ist es das empfohlene Datumsformat in Changelogs. + + %aside + Es gibt sicher noch mehr. Hilf mir alle schlechten Tipps zu sammeln, indem du + There’s more. Help me collect these antipatterns by + = link_to "ein Issue eröffnest", "#issues" + oder einen Pull-Request erstellst. + +.frequently-asked-questions + %h3#frequently-asked-questions + %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" } + Häufig gestellte Fragen + + %h4#standard + %a.anchor{ href: "#standard", aria_hidden: "true" } + Gibt es ein standardisiertes Changelog-Format + + %p + Not really. There's the GNU changelog style guide, or the two- + paragraph-long GNU NEWS file "guideline". Both are inadequate or + insufficient. + Leider nicht. Es gibt zwar den GNU Changelog Styleguide oder den + zwei Absätze langen GNU NEWS-Datei "Leitfaden". Beide sind aber + unzureichend. + + %p + Dieses Projekt versucht + = link_to "eine bessere Changelog Konvention zu sein.", changelog + Dazu beobachten wir bewährte Praktiken aus der Open Source Community + und tragen sie zusammen. + + %p + Gesunde Kritik, Diskussionen und Verbesserungsvorschläge + = link_to "sind herzlich willkommen.", issues + + + %h4#filename + %a.anchor{ href: "#filename", aria_hidden: "true" } + Wie sollte die Changelog-Datei benannt sein? + + %p + Nenne sie CHANGELOG.md. Manche Projekte verwenden auch + HISTORY, NEWS oder RELEASES. + + %p + Man könnte zwar meinen, dass der Name der Changelog-Datei keine große + Bedeutung hat, aber warum sollte man es den Endnutzern nicht einfach machen, + die Änderungen des Projekts zu finden, indem man einheitlichen Namen verwendet? + + + %h4#github-releases + %a.anchor{ href: "#github-releases", aria_hidden: "true" } + Was ist mit GitHub Releases? + + %p + Prinzipiell sind #{link_to "GitHub Releases", ghr} eine gute Sache. + Sie können dazu benutzt werden, um einfache Git Tags (zum Beispiel ein + Tag namens v1.0.0) mit vielen Hinweisen zum Release + auszustatten, indem man sie manuell bearbeitet, oder die Änderungen in eine + Git Tag Nachricht schreibt, wo sie durch GitHub automatisch in die + Release-Notizen gesetzt werden. + + %p + Leider lassen sich GitHub Releases aber nicht so einfach exportieren + und sind nur über GitHub selber zu lesen. Man kann sie auch so gestaltet, + dass sie dem Keep a Changelog Format sehr ähnlich sehen, aber dazu betreibt + man in der Regel einen größeren Aufwand. + + %p + Die derzeitige Version der GitHub Releases sind außerdem nicht leicht + durch die Endnutzer zu finden, ganz im Gegenteil zu den typischerweise + großgeschriebenen Dateien (README, CONTRIBUTING, etc.). + Ein weiterer kleiner Nachteil ist, dass das Web Interface zurzeit keinen Link + anbietet, um die Commits zwischen einzelnen Releases miteinander zu vergleichen. + + + %h4#automatic + %a.anchor{ href: "#automatic", aria_hidden: "true" } + Können Changelogs automatisiert ausgelesen werden? + + %p + Es ist schwierig, weil Menschen meist unterschiedliche Formate und + Dateinamen verwenden. + + %p + #{link_to "Vandamme", vandamme} ist ein Ruby gem erstellt vom + #{link_to "Gemnasium", gemnasium} Team, das viele (aber nicht alle) + Changelogs von Open Source Project einlesen kann. + + + %h4#yanked + %a.anchor{ href: "#yanked", aria_hidden: "true" } + Wie sieht es mit zurückgezogenen Releases aus? + + %p + Sogenannte "Yanked Releases" sind Versionen, welche wegen schwerwiegenden + Bugs oder Sicherheitsproblemen zurückgezogen werden mussten. Häufig kommen + diese im Changelog gar nicht vor, aber das sollten sie. So solltest Du diese + Versionen darstellen: + + %p ## 0.0.5 - 2014-12-13 [YANKED] + + %p + Der [YANKED] ist nicht ohne Grund großgeschrieben. Es ist wichtig, + dass sie von Menschen bemerkt werden. Weil er von eckigen Klammern umgeben ist, + kann man sie außerdem einfacher automatisiert einlesen. + + + %h4#rewrite + %a.anchor{ href: "#rewrite", aria_hidden: "true" } + Sollte ich ein Changelog je umschreiben? + + %p + Klar. Es gibt immer gute Gründe, ein Changelog zu verbessern. Ich öffne + regelmässig Pull Requests um Open-Source-Projekten mit schlecht gewarteten + Changelogs fehlende Releases hinzuzufügen. + + %p + Es ist auch möglich, dass Du eine wichtige Änderung vergessen hast, in einer + Version zu erwähnen. Natürlich ist es in diesem Fall wichtig, das Changelog + zu aktualisieren. + + + %h4#contribute + %a.anchor{ href: "#contribute", aria_hidden: "true" } + Wie kann ich mithelfen? + + %p + Dieses Dokument ist nicht die Wahrheit; Es ist meine wohl überlegte Meinung, + zusammen mit von mir zusammengetragenen Informationen und Beispielen. + + %p + So möchte ich erreichen, dass die Community einen Konsens finden. Ich glaube, dass + die Disskussion genauso wichtig ist wie das Endergebnis. + + %p + Also bitte #{link_to "bring dich ein", gh}. + +.press + %h3 Gespräche + %p + Ich habe im #{link_to "The Changelog podcast", thechangelog} darüber gesprochen, + warum sich Entwickler und Mitwirkende eines Projekts um ein Changelog kümmern sollten, + sowie meine Motivationen hinter diesem Projekt erklärt. From b5cf0e7122b0a77d171808a2d8482f17e7332b56 Mon Sep 17 00:00:00 2001 From: Robin Schneider Date: Tue, 20 Jun 2017 20:59:40 +0200 Subject: [PATCH 04/19] Pin format spec major versions You can only comply with a specification if you know it. Since new versions can are released without users knowing it immediately the only valid option is to pin the specification version which you know you comply with. Ref: https://github.com/olivierlacan/keep-a-changelog/issues/103 Used by: https://github.com/debops/ --- CHANGELOG.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 9324ba8..afa1333 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,8 +1,8 @@ # Changelog All notable changes to this project will be documented in this file. -The format is based on [Keep a Changelog](http://keepachangelog.com/) -and this project adheres to [Semantic Versioning](http://semver.org/). +The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) +and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html). ## [Unreleased] From 1e37b75b1ecdae00cfdce6324531c92ec6c84c7c Mon Sep 17 00:00:00 2001 From: Artur Weigandt Date: Tue, 20 Jun 2017 21:22:50 +0200 Subject: [PATCH 05/19] Fixes after review --- source/de/1.0.0/index.html.haml | 37 ++++++++++++++++----------------- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/source/de/1.0.0/index.html.haml b/source/de/1.0.0/index.html.haml index aecdd00..68596fd 100644 --- a/source/de/1.0.0/index.html.haml +++ b/source/de/1.0.0/index.html.haml @@ -33,25 +33,26 @@ version: 1.0.0 Was ist ein Changelog? %p - Ein Changelog ist eine Datei, welche eine handgepflegte, chronologisch sortierte - Liste aller erheblichen Änderungen enthält, die zwischen Veröffentlichungen (oder Versionen) - des Projekts umgesetzt wurden. + Ein Changelog ist eine Datei, die eine handgepflegte, chronologisch sortierte + Liste aller erheblichen Änderungen enthält, die zwischen einzelnen Veröffentlichungen + (oder Versionen) des Projekts umgesetzt wurden. %h3#why %a.anchor{ href: "#why", aria_hidden: "true" } Was ist der Zweck eines Changelogs? %p - Es Benutzern und Entwicklern einfacher zu machen, gerade die beachtenswerten Änderungen, welche - zwischen Veröffentlichungen (oder Versionen) des Projekts gemacht wurden, zu sehen. + Ein Changelog soll es Benutzern und Entwicklern einfacher machen, gerade die + beachtenswerten Änderungen, die zwischen Veröffentlichungen (oder Versionen) + des Projekts gemacht wurden, zu sehen. %h3#who %a.anchor{ href: "#who", aria_hidden: "true" } Wer braucht schon ein Changelog? %p - Menschen brauchen es. Seien es Konsumenten oder Entwickler, der Endnutzer der Software - sind Menschen, die es interessiert, was in der Software ist. Wenn sich die Software ändert, + Menschen brauchen es. Seien es Konsumenten oder Entwickler, die Endnutzer der Software + sind Menschen, die es interessiert, was in der Software passiert. Wenn sich die Software ändert, dann wollen diese Menschen wissen, wie und warum sie sich ändert. .good-practices @@ -69,15 +70,15 @@ version: 1.0.0 %li Für jede einzelne Version sollte es einen Eintrag geben. %li - Änderungen des selben Art sollten in Bereiche gruppiert werden. + Änderungen der selben Art sollten in Bereiche gruppiert werden. %li - Versionen und Bereiche sollten sollten verlinkt werden können. + Versionen und Bereiche sollten verlinkt werden können. %li Die neuste Version kommt als erstes. %li Das Release-Datum jeder Version muss angegeben sein. %li - Gibt ab, ob du dich an die #{link_to "Semantische Versionierung", semver} hältst. + Gib ab, ob du dich an die #{link_to "Semantische Versionierung", semver} hältst. %a.anchor{ href: "#types", aria_hidden: "true" } %h4#types Arten von Änderungen @@ -190,12 +191,9 @@ version: 1.0.0 %h4#standard %a.anchor{ href: "#standard", aria_hidden: "true" } - Gibt es ein standardisiertes Changelog-Format + Gibt es ein standardisiertes Changelog-Format? %p - Not really. There's the GNU changelog style guide, or the two- - paragraph-long GNU NEWS file "guideline". Both are inadequate or - insufficient. Leider nicht. Es gibt zwar den GNU Changelog Styleguide oder den zwei Absätze langen GNU NEWS-Datei "Leitfaden". Beide sind aber unzureichend. @@ -222,7 +220,8 @@ version: 1.0.0 %p Man könnte zwar meinen, dass der Name der Changelog-Datei keine große Bedeutung hat, aber warum sollte man es den Endnutzern nicht einfach machen, - die Änderungen des Projekts zu finden, indem man einheitlichen Namen verwendet? + die Änderungen des Projekts zu finden, indem man einen einheitlichen Namen + verwendet? %h4#github-releases @@ -231,7 +230,7 @@ version: 1.0.0 %p Prinzipiell sind #{link_to "GitHub Releases", ghr} eine gute Sache. - Sie können dazu benutzt werden, um einfache Git Tags (zum Beispiel ein + Sie können dazu benutzt werden, um einfache Git Tags (zum Beispiel einen Tag namens v1.0.0) mit vielen Hinweisen zum Release auszustatten, indem man sie manuell bearbeitet, oder die Änderungen in eine Git Tag Nachricht schreibt, wo sie durch GitHub automatisch in die @@ -289,7 +288,7 @@ version: 1.0.0 %p Klar. Es gibt immer gute Gründe, ein Changelog zu verbessern. Ich öffne - regelmässig Pull Requests um Open-Source-Projekten mit schlecht gewarteten + regelmässig Pull Requests, um Open-Source-Projekten mit schlecht gewarteten Changelogs fehlende Releases hinzuzufügen. %p @@ -303,11 +302,11 @@ version: 1.0.0 Wie kann ich mithelfen? %p - Dieses Dokument ist nicht die Wahrheit; Es ist meine wohl überlegte Meinung, + Dieses Dokument ist nicht die Wahrheit. Es ist meine wohl überlegte Meinung, zusammen mit von mir zusammengetragenen Informationen und Beispielen. %p - So möchte ich erreichen, dass die Community einen Konsens finden. Ich glaube, dass + So möchte ich erreichen, dass die Community einen Konsens findet. Ich glaube, dass die Disskussion genauso wichtig ist wie das Endergebnis. %p From de8082b5426aade5d0c1efc4c2a7aa1fcffea81b Mon Sep 17 00:00:00 2001 From: Artur Weigandt Date: Tue, 20 Jun 2017 22:05:16 +0200 Subject: [PATCH 06/19] Add fixes from @Capenus --- source/de/1.0.0/index.html.haml | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/source/de/1.0.0/index.html.haml b/source/de/1.0.0/index.html.haml index 68596fd..6ee1485 100644 --- a/source/de/1.0.0/index.html.haml +++ b/source/de/1.0.0/index.html.haml @@ -78,7 +78,7 @@ version: 1.0.0 %li Das Release-Datum jeder Version muss angegeben sein. %li - Gib ab, ob du dich an die #{link_to "Semantische Versionierung", semver} hältst. + Gib an, ob du dich an die #{link_to "Semantische Versionierung", semver} hältst. %a.anchor{ href: "#types", aria_hidden: "true" } %h4#types Arten von Änderungen @@ -162,7 +162,7 @@ version: 1.0.0 %p Auch wenn du sonst nichts geändert hast, liste trotzdem alle veralteten und - entfernten Features, sowie jede funktionsgefährdende Änderung in deinem Changlog auf. + entfernten Features, sowie jede funktionsgefährdende Änderung in deinem Changelog auf. %h4#confusing-dates @@ -174,13 +174,12 @@ version: 1.0.0 (06-02-2012 für den 2. Juni 2012), wohingegen viele Menschen im Rest der Welt ein roboterhaft aussehendes 2 June 2012 schreiben, aber es völlig unterschiedlich aussprechen. 2012-06-02 - folgt der Logik vom größten zum kleinsten Wert, kann nicht mit anderen Formate + folgt der Logik vom größten zum kleinsten Wert, kann nicht mit anderen Formaten verwechselt werden und ist ein #{link_to "ISO Standard", iso}. Deshalb ist es das empfohlene Datumsformat in Changelogs. %aside Es gibt sicher noch mehr. Hilf mir alle schlechten Tipps zu sammeln, indem du - There’s more. Help me collect these antipatterns by = link_to "ein Issue eröffnest", "#issues" oder einen Pull-Request erstellst. @@ -238,7 +237,7 @@ version: 1.0.0 %p Leider lassen sich GitHub Releases aber nicht so einfach exportieren - und sind nur über GitHub selber zu lesen. Man kann sie auch so gestaltet, + und sind nur über GitHub selber zu lesen. Man kann sie auch so gestalten, dass sie dem Keep a Changelog Format sehr ähnlich sehen, aber dazu betreibt man in der Regel einen größeren Aufwand. @@ -261,7 +260,7 @@ version: 1.0.0 %p #{link_to "Vandamme", vandamme} ist ein Ruby gem erstellt vom #{link_to "Gemnasium", gemnasium} Team, das viele (aber nicht alle) - Changelogs von Open Source Project einlesen kann. + Changelogs von Open-Source-Projekten einlesen kann. %h4#yanked From cdc41162cb3e0204044921c7f67fad0898726ae6 Mon Sep 17 00:00:00 2001 From: Olivier Lacan Date: Tue, 20 Jun 2017 21:11:38 +0100 Subject: [PATCH 07/19] Update CHANGELOG.md --- CHANGELOG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 9324ba8..a69194d 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -17,7 +17,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/). - "Frequently Asked Questions" section. - New "Guiding Principles" sub-section to "How do I make a changelog?". - Simplified and Traditional Chinese translations from @tianshuo. -- German translation from @mpbzh. +- German translation from @mpbzh & @Art4. - Italian translation from @roalz. - Swedish translation from @magol. - Turkish translation from @karalamalar. From 2ce658479ba480bcf299c3024aa675c794764355 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Magnus=20=C3=96sterlund?= Date: Tue, 20 Jun 2017 11:01:46 +0200 Subject: [PATCH 08/19] Swedish translation of v1.0.0 --- .gitignore | 1 + source/sv/1.0.0/index.html.haml | 300 ++++++++++++++++++++++++++++++++ 2 files changed, 301 insertions(+) create mode 100644 source/sv/1.0.0/index.html.haml diff --git a/.gitignore b/.gitignore index 865ecdb..ef48534 100644 --- a/.gitignore +++ b/.gitignore @@ -4,3 +4,4 @@ /.sass-cache /build /_site +/.vs diff --git a/source/sv/1.0.0/index.html.haml b/source/sv/1.0.0/index.html.haml new file mode 100644 index 0000000..875992e --- /dev/null +++ b/source/sv/1.0.0/index.html.haml @@ -0,0 +1,300 @@ +--- +description: Håll en ändringslogg +title: Håll en ändringslogg +language: sv +version: 1.0.0 +--- + +- changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md" +- gemnasium = "https://gemnasium.com/" +- gh = "https://github.com/olivierlacan/keep-a-changelog" +- issues = "https://github.com/olivierlacan/keep-a-changelog/issues" +- semver = "http://semver.org/" +- shields = "http://shields.io/" +- thechangelog = "http://5by5.tv/changelog/127" +- vandamme = "https://github.com/tech-angels/vandamme/" +- iso = "http://www.iso.org/iso/home/standards/iso8601.htm" +- ghr = "https://help.github.com/articles/creating-releases/" + +.header + .title + %h1 Håll en ändringslogg + %h2 Låt inte dina vänner slänga in git-loggar i ändringsloggar. + + = link_to changelog do + Version + %strong= current_page.metadata[:page][:version] + + %pre.changelog= File.read("CHANGELOG.md") + +.answers + %h3#what + %a.anchor{ href: "#what", aria_hidden: "true" } + Vad är en ändringslogg? + + %p + En ändringslogg är en fil innehållandes en sammanfattad, kronologiskt ordnad + lista över viktiga ändringar för varje version av ett projekt. + + %h3#why + %a.anchor{ href: "#why", aria_hidden: "true" } + Vad är meningen med en ändringslogg? + + %p + För att göra det enklare för användare och medarbetare att se exakt vilka + viktiga ändringar som har gjorts mellan varje utgåva (eller version) av projektet. + + %h3#who + %a.anchor{ href: "#who", aria_hidden: "true" } + Vem behöver en ändringslogg? + + %p + Alla behöver det. Oavsett om det är användare eller utvecklare, är + alla slutanvändare av mjukvaran människor som bryr sig vad som finns + i mjukvaran. När mjukvaran förändras vill folk veta varför och hur. + +.good-practices + %h3#how + %a.anchor{ href: "#how", aria_hidden: "true" } + Hur gör jag en bra ändringslogg? + + %h4#principles + %a.anchor{ href: "#principles", aria_hidden: "true" } + Riktlinjer + + %ul + %li + Ändringsloggar är för människor, inte maskiner. + %li + Det bör finnas en post för varje enskild version. + %li + Samma typ av ändringar bör grupperas. + %li + Det bör vara möjligt att länka till versioner och sektioner. + %li + Senaste versionen kommer först. + %li + Datum då respektive version släpptes ska visas. + %li + Notering att du följer #{link_to "Semantic Versioning", semver}. + + %a.anchor{ href: "#types", aria_hidden: "true" } + %h4#types Typer av ändringar + + %ul + %li + %code Added + för nya funktioner. + %li + %code Changed + för ändringar på existerande funktionalitet. + %li + %code Deprecated + för funktionalitet som snart tas bort. + %li + %code Removed + för nu borttagen funktionalitet. + %li + %code Fixed + för alla buggfixar + %li + %code Security + i fall av sårbarheter. + +.effort + + %h3#effort + %a.anchor{ href: "#effort", aria_hidden: "true" } + Hur kan jag minimera den insats som krävs för att underhålla en ändringslogg? + + %p + Ha en sektion kallad Unreleased högst upp för att hålla reda på + kommande ändringar. + + %p Detta tjänar två syften: + + %ul + %li + Folk kan se vilka ändringar de kan förvänta sig i kommande utgåvor + %li + Vid lansering behöver du bara flytta innehållet i sektionen + Unreleased till en ny versionspost. + +.bad-practices + %h3#bad-practices + %a.anchor{ href: "#bad-practices", aria_hidden: "true" } + Kan ändringsloggar vara dåliga? + + %p Ja, här är några exempel på då de är mindre användbara. + + %h4#log-diffs + %a.anchor{ href: "#log-diffs", aria_hidden: "true" } + Diffar från incheckningsloggen. + + %p + Det är en dålig idé att använda incheckningsloggen som ändringslogg: + de är fulla av brus. Saker så som merge-incheckningar, incheckningar med + otydliga titlar, dokumentationsförändringar etc. + + %p + Syftet med en incheckning är att dokumentera ett steg i utvecklingen av + källkoden. Vissa projekt städar upp bland incheckningarna, andra inte. + + %p + Syftet med en post i en ändringslogg är att dokumentera den noterbara + skillnaden, oftast över flera incheckningar, för att kommunicera dessa + tydligt till slutanvändaren. + + %h4#ignoring-deprecations + %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" } + Ignorera föråldrad funktionalitet (deprecations) + + %p + När användare uppgraderar från en version till en annan, ska det vara + smärtsamt uppenbart när något förväntas gå sönder. Den bör vara möjligt + att uppgradera till en version som listar föråldrad funktionalitet, ta + bort dessa beroenden i sitt program, och sedan uppgradera till en version + där den föråldrade funktionaliteten är borttagen. + + %p + Om du inte gör något annat, lista åtminstone föråldrad och borttagen + funktionalitet samt förstörande förändringar i din ändringslogg. + + %h4#confusing-dates + %a.anchor{ href: "#confusing-dates", aria_hidden: "true" } + Förvillande datum + + %p + I USA lägger folk månaden först (06-02-2012 för 2:a juni 2012), + medan många andra runt om i världen skriver 2 June 2012 men + uttalar det annorlunda. 2012-06-02 fungerar logiskt från störst + till minst, överlappar inte på något tvetydligt sätt med andra datumformat, + och är en #{link_to "ISO-standard", iso}. Dessutom är det rekommenderat + datumformat för ändringsloggar. + + %aside + Det finns mer. Hjälp mig att samla dessa antimönster + genom att = link_to "skapa ett issue", "#issues" eller en pull requests + +.frequently-asked-questions + %h3#frequently-asked-questions + %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" } + Vanliga frågor + + %h4#standard + %a.anchor{ href: "#standard", aria_hidden: "true" } + Finns det ett standardformat på ändringsloggar? + + %p + Inte riktigt. GNU:s stilguide för ändringsloggar och den två stycke + långa GNU NEWS-filen med riktlinjer finns. Båda är bristfälliga och + otillräckliga. + + %p + Detta projekt har som mål att bli + = link_to "en bättre konvention för ändringsloggar.", changelog + Det utgår från uppenbart goda praxis från öppen källkods-världen och sammanför dem. + + %p + Konstruktiv kritik, diskussion och förslag till förbättring + = link_to "är välkommen.", issues + + %h4#filename + %a.anchor{ href: "#filename", aria_hidden: "true" } + Vad bör filen med ändringsloggen heta? + + %p + Döp den till CHANGELOG.md. En del projekt använder + HISTORY, NEWS eller RELEASES. + + %p + Även om det är lätt att tänka att det inte spelar så stor roll vad filen + med ändringsloggar kallas, varför göra det svårare för dina slutanvändare + att enkelt hitta de viktigaste ändringarna? + + %h4#github-releases + %a.anchor{ href: "#github-releases", aria_hidden: "true" } + Hur är det med GitHub Releases? + + %p + Det är ett fantasiskt initiativ. #{link_to "Releases", ghr} kan användas + för att göra enkla git-taggar (t.ex. en tagg kallad v1.0.0) + till formaterade versionsanteckningar genom att manuellt lägga till + versionsanteckningar eller så kan den hämta meddelandena i kommenterade + git-taggar och omvandla dessa till versionsanteckningar. + + %p + GitHub Releases skapar en icke porterbar ändringslogg som enbart kan visas + för användare på GitHub. Det är möjligt att formatera det ungefär som på + Håll en ändringslogg-formatet, men det tendera att bli lite mer invecklat. + + %p + Nuvarande version av GitHub releases är möjligtvis också lite svår att + hitta för slutanvändare, till skillnad från filer med normalt stora + bokstäver (README, CONTRIBUTING, etc.). + Ett annat bekymmer är att användargränssnittet för närvarande inte + erbjuder länkar till incheckningsloggar mellan olika versioner. + + %h4#automatic + %a.anchor{ href: "#automatic", aria_hidden: "true" } + Kan ändringsloggar bli automatiskt tolkade? + + %p + Det är svårt då människor följer vitt olika format och filnamn. + + %p + #{link_to "Vandamme", vandamme} är en Ruby gem skapad av gruppen + #{link_to "Gemnasium", gemnasium} som tolkar många (men inte alla) + ändringsloggar för öppen källkod. + + %h4#yanked + %a.anchor{ href: "#yanked", aria_hidden: "true" } + Hur är det med brådskande utgåvor ("yanked")? + + %p + Brådskande utgåvor är versioner som måste släppas på grund av alvarliga + buggar eller säkerhetsproblem. Oftast brukar dessa versioner inte ens + finnas med i ändringsloggarna. De borde det. Så här borde du visa dem: + + %p ## 0.0.5 - 2014-12-13 [YANKED] + + %p + Taggen [YANKED] står ut av en anledning, det är viktigt + att folk se det. Då den är omsluten med hakparenteser är det också lättare + för ett program att tolka det. + + %h4#rewrite + %a.anchor{ href: "#rewrite", aria_hidden: "true" } + Borde du någonsin förändra en ändringslogg? + + %p + Självklart. Det finns alltid en bra anledning att förbättra en ändringslogg. + Jag öppnar regelbundet pull requests för att lägga till saknade utgåvor + för öppna källkodsprojekt som inte tar hand om sin ändringslogg. + + %p + Det kan också hända att du upptäcker att du glömt att ta upp en icke + bakåtkompatibel förändring i en version. I sådana fall är det självklart + viktigt att uppdatera din ändringslogg. + + %h4#contribute + %a.anchor{ href: "#contribute", aria_hidden: "true" } + Hur kan jag bidra? + + %p + Detta dokument är inte sanningen, det är en noga övervägd + åsikt tillsammans med information och exempel jag har samlat på mig. + + %p + Detta beror på att jag vill att vår gemenskap ska nå enighet. Jag tror på + att diskussionen är lika viktig som slutresultatet. + + %p + Så tveka inte att #{link_to kasta dig in i diskussionen, gh}. + +.press + %h3 Samtal + %p + Jag var med i #{link_to "The Changelog podcast", thechangelog} + för att prata om varför förvaltare och bidragsgivare bör bry sig om + ändringsloggar, och motiveringen bakom detta projekt. From 9b525bc076c53633b7744c52cde4254fdb9b0195 Mon Sep 17 00:00:00 2001 From: Olivier Lacan Date: Tue, 20 Jun 2017 21:53:10 +0100 Subject: [PATCH 09/19] Fix Turkish language code in 1.0.0 --- source/tr-TR/1.0.0/index.html.haml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/tr-TR/1.0.0/index.html.haml b/source/tr-TR/1.0.0/index.html.haml index 24b9a07..e09ad75 100644 --- a/source/tr-TR/1.0.0/index.html.haml +++ b/source/tr-TR/1.0.0/index.html.haml @@ -1,7 +1,7 @@ --- description: Değişiklik kaydı tutun title: Değişiklik kaydı tutun -language: tr +language: tr-TR version: 1.0.0 --- @@ -175,7 +175,7 @@ version: 1.0.0 önerilen tarih biçimidir. %aside - Dahası da var. Bu karşıt desenleri toplamam için + Dahası da var. Bu karşıt desenleri toplamam için = link_to "bir çağrı açın", "#issues" ua da bir çekme isteği gönderin. @@ -238,7 +238,7 @@ version: 1.0.0 Ayrıca GitHub dağıtımlarının şu anki hali son kullanıcılar tarafından çok kolay bulunabilir değil. Tipik büyük harfli dosyalar (README, CONTRIBUTING, vb.) daha çok göze - çarpıyor. Bir başka konu da mevcut arayüz her dağıtım arasındaki + çarpıyor. Bir başka konu da mevcut arayüz her dağıtım arasındaki commit kayıtlarına bağlantı vermeye izin vermiyor.. %h4#automatic From 109c17709d8fae87c5eb494821eac293e6dad510 Mon Sep 17 00:00:00 2001 From: Olivier Lacan Date: Tue, 20 Jun 2017 21:54:49 +0100 Subject: [PATCH 10/19] Fix broken link in Swedish 1.0.0 --- source/sv/1.0.0/index.html.haml | 54 ++++++++++++++++----------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/source/sv/1.0.0/index.html.haml b/source/sv/1.0.0/index.html.haml index 875992e..543d9d1 100644 --- a/source/sv/1.0.0/index.html.haml +++ b/source/sv/1.0.0/index.html.haml @@ -64,7 +64,7 @@ version: 1.0.0 %ul %li - Ändringsloggar är för människor, inte maskiner. + Ändringsloggar är för människor, inte maskiner. %li Det bör finnas en post för varje enskild version. %li @@ -117,7 +117,7 @@ version: 1.0.0 %li Folk kan se vilka ändringar de kan förvänta sig i kommande utgåvor %li - Vid lansering behöver du bara flytta innehållet i sektionen + Vid lansering behöver du bara flytta innehållet i sektionen Unreleased till en ny versionspost. .bad-practices @@ -132,8 +132,8 @@ version: 1.0.0 Diffar från incheckningsloggen. %p - Det är en dålig idé att använda incheckningsloggen som ändringslogg: - de är fulla av brus. Saker så som merge-incheckningar, incheckningar med + Det är en dålig idé att använda incheckningsloggen som ändringslogg: + de är fulla av brus. Saker så som merge-incheckningar, incheckningar med otydliga titlar, dokumentationsförändringar etc. %p @@ -150,14 +150,14 @@ version: 1.0.0 Ignorera föråldrad funktionalitet (deprecations) %p - När användare uppgraderar från en version till en annan, ska det vara + När användare uppgraderar från en version till en annan, ska det vara smärtsamt uppenbart när något förväntas gå sönder. Den bör vara möjligt att uppgradera till en version som listar föråldrad funktionalitet, ta - bort dessa beroenden i sitt program, och sedan uppgradera till en version + bort dessa beroenden i sitt program, och sedan uppgradera till en version där den föråldrade funktionaliteten är borttagen. %p - Om du inte gör något annat, lista åtminstone föråldrad och borttagen + Om du inte gör något annat, lista åtminstone föråldrad och borttagen funktionalitet samt förstörande förändringar i din ändringslogg. %h4#confusing-dates @@ -165,15 +165,15 @@ version: 1.0.0 Förvillande datum %p - I USA lägger folk månaden först (06-02-2012 för 2:a juni 2012), - medan många andra runt om i världen skriver 2 June 2012 men - uttalar det annorlunda. 2012-06-02 fungerar logiskt från störst - till minst, överlappar inte på något tvetydligt sätt med andra datumformat, - och är en #{link_to "ISO-standard", iso}. Dessutom är det rekommenderat + I USA lägger folk månaden först (06-02-2012 för 2:a juni 2012), + medan många andra runt om i världen skriver 2 June 2012 men + uttalar det annorlunda. 2012-06-02 fungerar logiskt från störst + till minst, överlappar inte på något tvetydligt sätt med andra datumformat, + och är en #{link_to "ISO-standard", iso}. Dessutom är det rekommenderat datumformat för ändringsloggar. %aside - Det finns mer. Hjälp mig att samla dessa antimönster + Det finns mer. Hjälp mig att samla dessa antimönster genom att = link_to "skapa ett issue", "#issues" eller en pull requests .frequently-asked-questions @@ -186,9 +186,9 @@ version: 1.0.0 Finns det ett standardformat på ändringsloggar? %p - Inte riktigt. GNU:s stilguide för ändringsloggar och den två stycke - långa GNU NEWS-filen med riktlinjer finns. Båda är bristfälliga och - otillräckliga. + Inte riktigt. GNU:s stilguide för ändringsloggar och den två stycke + långa GNU NEWS-filen med riktlinjer finns. Båda är bristfälliga och + otillräckliga. %p Detta projekt har som mål att bli @@ -218,20 +218,20 @@ version: 1.0.0 %p Det är ett fantasiskt initiativ. #{link_to "Releases", ghr} kan användas - för att göra enkla git-taggar (t.ex. en tagg kallad v1.0.0) - till formaterade versionsanteckningar genom att manuellt lägga till - versionsanteckningar eller så kan den hämta meddelandena i kommenterade + för att göra enkla git-taggar (t.ex. en tagg kallad v1.0.0) + till formaterade versionsanteckningar genom att manuellt lägga till + versionsanteckningar eller så kan den hämta meddelandena i kommenterade git-taggar och omvandla dessa till versionsanteckningar. %p GitHub Releases skapar en icke porterbar ändringslogg som enbart kan visas för användare på GitHub. Det är möjligt att formatera det ungefär som på Håll en ändringslogg-formatet, men det tendera att bli lite mer invecklat. - + %p Nuvarande version av GitHub releases är möjligtvis också lite svår att - hitta för slutanvändare, till skillnad från filer med normalt stora - bokstäver (README, CONTRIBUTING, etc.). + hitta för slutanvändare, till skillnad från filer med normalt stora + bokstäver (README, CONTRIBUTING, etc.). Ett annat bekymmer är att användargränssnittet för närvarande inte erbjuder länkar till incheckningsloggar mellan olika versioner. @@ -243,10 +243,10 @@ version: 1.0.0 Det är svårt då människor följer vitt olika format och filnamn. %p - #{link_to "Vandamme", vandamme} är en Ruby gem skapad av gruppen + #{link_to "Vandamme", vandamme} är en Ruby gem skapad av gruppen #{link_to "Gemnasium", gemnasium} som tolkar många (men inte alla) ändringsloggar för öppen källkod. - + %h4#yanked %a.anchor{ href: "#yanked", aria_hidden: "true" } Hur är det med brådskande utgåvor ("yanked")? @@ -276,7 +276,7 @@ version: 1.0.0 Det kan också hända att du upptäcker att du glömt att ta upp en icke bakåtkompatibel förändring i en version. I sådana fall är det självklart viktigt att uppdatera din ändringslogg. - + %h4#contribute %a.anchor{ href: "#contribute", aria_hidden: "true" } Hur kan jag bidra? @@ -287,10 +287,10 @@ version: 1.0.0 %p Detta beror på att jag vill att vår gemenskap ska nå enighet. Jag tror på - att diskussionen är lika viktig som slutresultatet. + att diskussionen är lika viktig som slutresultatet. %p - Så tveka inte att #{link_to kasta dig in i diskussionen, gh}. + Så tveka inte att #{link_to "kasta dig in i diskussionen", gh}. .press %h3 Samtal From 289868301f5c658be82212e1db6cfef17df467d0 Mon Sep 17 00:00:00 2001 From: zapashcanon Date: Wed, 21 Jun 2017 00:21:18 +0200 Subject: [PATCH 11/19] Fix french translation --- source/fr/1.0.0/index.html.haml | 60 ++++++++++++++++----------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/source/fr/1.0.0/index.html.haml b/source/fr/1.0.0/index.html.haml index c90ff33..c5b3a62 100644 --- a/source/fr/1.0.0/index.html.haml +++ b/source/fr/1.0.0/index.html.haml @@ -33,7 +33,7 @@ version: 1.0.0 Qu'est-ce qu'un changelog ? %p - Un changelog (journal de modifications) est un fichier qui contient + Un changelog (journal des modifications) est un fichier qui contient une liste triée chronologiquement des changements notables pour chaque version d’un projet @@ -42,8 +42,8 @@ version: 1.0.0 Pourquoi tenir un changelog ? %p - Pour permettre aux utilisateurs et contributeurs de voir précisement - quel changements notables ont été faits entre chaque publication + Pour permettre aux utilisateurs et contributeurs de voir précisément + quels changements notables ont été faits entre chaque publication (ou version) d'un projet. %h3#who @@ -51,10 +51,10 @@ version: 1.0.0 Qui a besoin d'un changelog ? %p - Tout le monde. Qu'ils soient consomateurs ou developeurs, les + Tout le monde. Qu'ils soient consommateurs ou développeurs, les utilisateurs de logiciels sont des êtres humains qui se soucient de connaître le contenu des logiciels qu'ils utilisent. Quand un - logiciel change, ces même personnes veulent savoir comment et pourquoi. + logiciel change, ces mêmes personnes veulent savoir comment et pourquoi. .good-practices %h3#how @@ -69,7 +69,7 @@ version: 1.0.0 %li Les changelogs sont pour les êtres humains, pas les machines. %li - Il doit il y avoir une section pour chaque version. + Il doit y avoir une section pour chaque version. %li Les changements similaires doivent être groupés. %li @@ -102,7 +102,7 @@ version: 1.0.0 pour les corrections de bugs. %li %code Security - en cas de vulnerabilités. + en cas de vulnérabilités. .effort @@ -114,11 +114,11 @@ version: 1.0.0 Gardez une section Unreleased en haut du fichier afin de lister tous les changements qui n'ont pas encore été publiés. - %p Cela rempli deux objectifs: + %p Cela permet deux choses: %ul %li - Les gens peuvent voir les changements auxquels ils peuvent s’attendrent + Les gens peuvent voir les changements auxquels ils peuvent s’attendre dans les prochaines publications. %li Au moment de la publication, vous pouvez déplacer les changements listés @@ -134,12 +134,12 @@ version: 1.0.0 %h4#log-diffs %a.anchor{ href: "#log-diffs", aria_hidden: "true" } - Diffs de journaux git + Diffs de journaux gits %p - Utiliser des diffs de journaux git en tant que changelogs est une mauvaise - idée: ils sont remplis de bruit. Les journaux git sont remplis de choses - comme des commits de merge, des commits avec des titres obscures, des + Utiliser des diffs de journaux gits en tant que changelogs est une mauvaise + idée: ils sont remplis de bruit. Les journaux gits sont remplis de choses + comme des commits de merge, des commits avec des titres obscurs, des changements concernant la documentation, etc. %p @@ -147,9 +147,9 @@ version: 1.0.0 source. Certains projets nettoient leurs commits, d'autres non. %p - Le but d'une section de changelog est de documenter la difference notable - entre deux versions, souvent à travers de multiples commits, afin de la - communiquer clairement aux utilisateurs. + Le but d'une section de changelog est de documenter les différences + notables entre deux versions, souvent à travers de multiples + commits, afin de les communiquer clairement aux utilisateurs. %h4#ignoring-deprecations %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" } @@ -157,7 +157,7 @@ version: 1.0.0 %p Lorsque l'on passe d'une version d'un logiciel à une autre, il devrait être - très clair si quelque chose peut ne pas fonctionner. Il devrait être + très clair si quelque chose peut ne plus fonctionner. Il devrait être possible de mettre à jour vers un version qui offre une liste des fonctionnalités dépréciées, de retirer ce qui est déprécié, puis de mettre à jour vers la version où les dépréciations deviennent des suppressions de @@ -180,10 +180,10 @@ version: 1.0.0 prononcent différement. 2012-06-02 fonctionne logiquement, du plus grand au plus petit, ne laisse pas place à la confusion avec un autre format et est un #{link_to "standard ISO", iso}. C'est pour cela que ce format de date - est recommandé pour les change logs. + est recommandé pour les changelogs. %aside - Il y en a d’autres. Aidez-moi à collecter ces anti-patrons en + Il y en a d’autres. Aidez-moi à collecter ces antipatrons en #{link_to "ouvrant une issue", "#issues"} ou une pull request. .frequently-asked-questions @@ -198,7 +198,7 @@ version: 1.0.0 %p Pas vraiment. Il y a le guide de style GNU pour les changelogs, ou les instructions GNU de deux paragraphes pour les fichiers NEWS. Ces deux - resources sont inappropriées et insuffisantes. + ressources sont inappropriées et insuffisantes. %p Ce projet vise à devenir @@ -213,16 +213,16 @@ version: 1.0.0 %h4#filename %a.anchor{ href: "#filename", aria_hidden: "true" } - Comment doit-être nommé le fichier de change log ? + Comment doit-être nommé le fichier de changelog ? %p - Nommez le CHANGELOG.md. Certains projects utilisent + Nommez-le CHANGELOG.md. Certains projets utilisent HISTORY, NEWS ou RELEASES. %p Même s'il est facile d'imaginer que le nom d'un fichier de changelog n'a - pas grant interêt, pourquoi rendre la tâche difficile que nécessaire pour - les utilisateurs qui cherchent à trouver les changements notables de votre + pas grand intérêt, pourquoi rendre la tâche plus difficile que nécessaire + aux utilisateurs qui cherchent à trouver les changements notables de votre projet ? %h4#github-releases @@ -238,19 +238,19 @@ version: 1.0.0 %p GitHub Releases crée un changelog non-portable qui n'est visible par les - utilisateurs qu'à l'interieur du context de GitHub. Il est possible de + utilisateurs qu'à l'intérieur du contexte de GitHub. Il est possible de suivre le même format que Keep a Changelog, mais c'est plus difficile. %p La version actuelle de GitHub Releases est également difficile à découvrir pour les utilisateurs, contrairement aux fichiers en majuscules typiques - (README, CONTRIBUTING, etc.). Un autre soucis - mineur est que l'interface ne permet pas actuellement d'offrir des liens - vers les journaux git entre chaque publication. + (README, CONTRIBUTING, etc.). Un autre souci + mineur est que l'interface n'offre actuellement pas de lien vers les + journaux gits entre chaque publication. %h4#automatic %a.anchor{ href: "#automatic", aria_hidden: "true" } - Les change logs peuvent-ils être parsés automatiquement ? + Les changelogs peuvent-ils être parsés automatiquement ? %p C'est difficile, parce que les gens suivent des formats et utilisent des noms @@ -258,7 +258,7 @@ version: 1.0.0 %p #{link_to "Vandamme", vandamme} est une Ruby gem créée par l'équipe - #{link_to "Gemnasium", gemnasium} qui parse les change logs de + #{link_to "Gemnasium", gemnasium} qui parse les changelogs de beaucoup (mais pas tous) de projets open source. From 1eb09dd8015889cd9097bc28ba32cb69165c837e Mon Sep 17 00:00:00 2001 From: Alexandr Borisov Date: Wed, 21 Jun 2017 11:07:51 +0300 Subject: [PATCH 12/19] Added ru translation for version 1.0.0 --- source/ru/1.0.0/index.html.haml | 197 ++++++++++++++++++++++++++++++++ 1 file changed, 197 insertions(+) create mode 100644 source/ru/1.0.0/index.html.haml diff --git a/source/ru/1.0.0/index.html.haml b/source/ru/1.0.0/index.html.haml new file mode 100644 index 0000000..1c6c2c6 --- /dev/null +++ b/source/ru/1.0.0/index.html.haml @@ -0,0 +1,197 @@ +--- +description: Ведите Changelog +title: Ведите Changelog +language: en +version: 0.3.0 +--- + +:markdown + # Ведите CHANGELOG + + ## Не позволяйте друзьям сливать логи гита в CHANGELOG™ + + Version **#{current_page.metadata[:page][:version]}** + + ### Что такое лог изменений? + Лог изменений – это файл, который содержит поддерживаемый, хронологически упорядоченный + список изменений для каждой версии проекта. + +%pre.changelog= File.read("CHANGELOG.md") + +:markdown + ### Для чего нужен лог изменений? + Чтобы пользователи и контрибьюторы чётко понимали что поменялось в каждом релизе (или + версии) проекта. + + ### Почему я вообще должен задумываться о таких вещах? + Потому, что инструменты программирования делаются для людей. Если вам пофигу, + зачем вы вообще занимаетесь программным обеспечением с открытым исходным + кодом? У вас обязательно в голове должен быть центр «не пофигу» :) + + Я [беседовал с Адамом Стаковиаком и с Джеродом Санто в подкасте The + Changelog][thechangelog] (в тему название, правда?) о том почему авторам + программного обеспечения с открытым исходным кодом и их коллегам должно быть + не пофигу, и о моих мотивах в создании этого проекта. Послушайте, если у вас + есть время (1:06). + + ### Что должно быть в хорошем логе изменений? + Я рад, что вы спросили. + + Хороший лог изменений построен на таких приниципах: + + - Он сделан для людей, а не машин, так что понятность имеет решающее + значение. + - Легко сослаться на любой раздел (поэтому Markdown лучше обычного текста). + - Один подраздел на каждую версию. + - Релизы перечислены в обратном хронологическом порядке (самые новые – + сверху). + - Пишите все даты в формате `YYYY-MM-DD`. (Например: `2012-06-02` для даты `2 + июня 2012`.) Он международный, [рациональный](http://xkcd.com/1179/), и + независим от языка. + - Ясно указывает, использует ли проект [Семантическое + Версионирование][semver]. + - Каждая версия должна: + - Показывать дату релиза в формате, упомянутом выше. + - Группировать изменения согласно их влиянию на проект следующим образом: + - `Added` для новых функций. + - `Changed` для изменений в существующей функциональности. + - `Deprecated` для функциональности, которая будет удалена в следующих + версиях. + - `Removed` для функциональности, которая удалена в этой версии. + - `Fixed` для любых исправлений. + - `Security` для обновлений безопасности. + + ### Как минимизировать время, необходимое для ведения лога изменений? + Всегда ведите секцию `Unreleased` в начале файла, чтобы держать в ней не + выпущенные изменения. + + Это нужно для двух вещей: + + - Люди смогут видеть, какие изменения ожидаются в ближайших релизах + - В момент релиза вам нужно всего лишь заменить секцию `Unreleased` на номер + версии и добавить новую секцию `Unreleased` в начале файла. + + ### Что заставляет плакать единорогов? + Хорошо… давайте разберёмся. + + - **Выгрузка изменений лога коммитов.** Просто не делайте так, это никому не + принесёт пользы. + - **Отсутствие отметок планируемой к удалению функциональности.** Когда люди + обновляются от одной версии к другой, им должно быть очевидно до боли, что + сломается. + - **Даты в местном формате.** В Соединённых Штатах, люди сначала пишут месяц + («06-02-2012» для даты 2 июня 2012, что не имеет *никакого* смысла), хотя + много людей в остальном мире пишет роботоподобное «2 июня 2012», всё ещё + произнося это по-другому. «2012-06-02» логично работает от самого большого + к самому маленькому, не пересекается с другими форматами дат, и является + [стандартом ISO](http://www.iso.org/iso/home/standards/iso8601.htm). Таким + образом, этот формат является рекомендуемым для логов изменений. + + Существуют и другие. Помогите мне собрать слёзы единорогов, + [открыв тикет][issues] или пулл-реквест. + + ### Существует стандарт формата лога изменений? + К сожалению, нет. Спокойней. Я знаю, что вы яростно бросились на поиски + ссылки на GNU-руководства по стилю лога изменений, или на поиски файла + «guideline» с парой параграфов в GNU NEWS. GNU-руководство по стилю неплохо + для начала, но оно наивно. В наивности нет ничего плохого, но когда людям + нужно руководство, она редко бывает полезна. Особенно, когда приходиться + сталкиваться со множеством краевых случаев. + + Этот проект [содержит информацию, которая, я надеюсь, станет соглашением + получше о ведении файлов CHANGELOG][CHANGELOG] для всех проектов с открытым + исходным кодом. Может ли сообщество учиться на своих ошибках, а не просто + действовать согласно десяти записям, которые были написаны много лет назал, + и, якобы, без одной ошибки? Хорошо. Поэтому, пожалуйста, посмотрите вокруг, и + помните, что [обсуждения и предложения по улучшению приветствуются][issues]! + + ### Как можно назвать файл лога изменений? + Ну, если вы не не можете ответить на этот вопрос, глядя на пример выше, + `CHANGELOG.md` пока наилучший вариант. + + Некоторые проекты используют `HISTORY.txt`, `HISTORY.md`, `History.md`, + `NEWS.txt`, `NEWS.md`, `News.txt`, `RELEASES.txt`, `RELEASE.md`, + `releases.md`, и так далее. + + Это непорядок. Все эти имена только усложняют поиск нужного файла. + + ### Почему люди не могут использовать просто дифф команды `git log`? + Потому, что диффы логов по своей природе содержат слишком много «шума». С их + помощью невозможно сделать подходящий лог изменений даже в гипотетическом + проекте, который делается идеальными программистами, которые никогда не + делают опечаток, никогда не забывают коммитить новые файлы, никогда не + пропускают ни одну часть рефакторинга. Назначение коммита в том, чтобы + задокументировать один атомарный шаг в процессе развития кода от одного + состояния к другому. Назначение лога изменений – документировать значимые + различия между этими состояниями. + + Как отличаются хорошие комментарии к коду и сам код, также отличаются друг от + друга и лог изменений с логом коммитов: первые отвечают на вопрос + *почему*, а вторые на вопрос как. + + ### Могут ли логи изменений быть автоматически распарсены? + Это сложно из-за того, что люди следуют сильно отличающимся форматам и + соглашениям о именах файлов. + + Гем для Руби [Vandamme][vandamme], который создали в команде + [Gemnasium][gemnasium], парсит многие (но не все) логи изменений проектов с + открытым исходным кодом. + + ### Почему вы пишите то «CHANGELOG», то «лог изменений»? + «CHANGELOG» – это имя файла. Оно несколько крикливо, но это историческое + соглашение, которому следуют многие проекты с открытым исходным кодом. В + качестве примеров подобных файлов можно привести [`README`][README], + [`LICENSE`][LICENSE], и [`CONTRIBUTING`][CONTRIBUTING]. + + Верхний регистр в имени файла (который в старых операционных системах + заставляет эти файлы находиться наверху списков) используется для привлечения + внимания. Так как в этих файлах содержится важная метаинформация о проекте, + они могут быть полезны любому использующему или дорабатывющему проект, также + как [бейджи проектов с открытым исходным кодом][shields]. + + Когда я упоминаю «лог изменений», я говорою о назначении этого файла: об + учёте изменений. + + ### Как насчёт yanked-релизов? + Yanked-релизы – это версии, которые изымаются из обращения из-за серьёзного + бага или проблемы безопасности в них. Часто такие версии даже не упоминаются + в логах изменений. А должны. И вот как вам следует их упоминать: + + `## 0.0.5 - 2014-12-13 [YANKED]` + + Тег `[YANKED]` такой «громкий» не просто так. Очень важно, чтобы люди его + заметили. А из-за того, что он окружён скобками, его легче определить + программно. + + ### Стоит ли переписывать лог изменений? + Конечно. Всегда есть причины для улучшения лога изменений. Я регулярно + открываю пулл-реквесты в проекты с открытым исходным кодом с + неподдерживаемыми логами изменений для добавления недостающих релизов. + + Также вы можете обнаружить что вы забыли адресовать критичное изменение в + описании версии. В этом случае очевидно, что нужно обновить лог + изменений. + + ### Как я могу помочь вашему проекту? + Этот документ **не истина в последней инстанции**; это моё тщательно + сформулированное мнение вместе с информацией и примерами, которые я собрал. + Хотя я предоставил настоящий [CHANGELOG][] из [GitHub-репозитария][gh], я + специально избегал цели создать *стандарт* или чёткий список правил (как это + делает, например, [SemVer.org][semver]). + + Я сделал это потому, что хочу, чтобы наше сообщество достигло консенсуса. Я + верю, что дискуссия также важна, как и её результат. + + Так что, пожалуйста, [**участвуйте**][gh]. + + [CHANGELOG]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md + [CONTRIBUTING]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CONTRIBUTING.md + [LICENSE]: https://github.com/olivierlacan/keep-a-changelog/blob/master/LICENSE + [README]: https://github.com/olivierlacan/keep-a-changelog/blob/master/README.md + [gemnasium]: https://gemnasium.com/ + [gh]: https://github.com/olivierlacan/keep-a-changelog + [issues]: https://github.com/olivierlacan/keep-a-changelog/issues + [semver]: http://semver.org/ + [shields]: http://shields.io/ + [thechangelog]: http://5by5.tv/changelog/127 + [vandamme]: https://github.com/tech-angels/vandamme/ From 662caf1ce9d0e5f5633d3e9a3b4b0dfa528a1fc5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Magnus=20=C3=96sterlund?= Date: Wed, 21 Jun 2017 10:49:15 +0200 Subject: [PATCH 13/19] sv/1.0.0 - Fix link --- source/sv/1.0.0/index.html.haml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/source/sv/1.0.0/index.html.haml b/source/sv/1.0.0/index.html.haml index 875992e..dad19c9 100644 --- a/source/sv/1.0.0/index.html.haml +++ b/source/sv/1.0.0/index.html.haml @@ -76,7 +76,7 @@ version: 1.0.0 %li Datum då respektive version släpptes ska visas. %li - Notering att du följer #{link_to "Semantic Versioning", semver}. + Notering att du följer #{link_to "Semantisk versionshantering", semver}. %a.anchor{ href: "#types", aria_hidden: "true" } %h4#types Typer av ändringar @@ -173,8 +173,9 @@ version: 1.0.0 datumformat för ändringsloggar. %aside - Det finns mer. Hjälp mig att samla dessa antimönster - genom att = link_to "skapa ett issue", "#issues" eller en pull requests + Det finns mer. Hjälp mig att samla dessa antimönster genom att + = link_to "skapa ett issue", "#issues" + eller en pull requests .frequently-asked-questions %h3#frequently-asked-questions From 225c404ed4835851814b884e3e93ce0382449dbc Mon Sep 17 00:00:00 2001 From: Olivier Lacan Date: Wed, 21 Jun 2017 13:40:10 +0100 Subject: [PATCH 14/19] Use interpolated link --- source/sv/1.0.0/index.html.haml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/source/sv/1.0.0/index.html.haml b/source/sv/1.0.0/index.html.haml index 075736b..8803f09 100644 --- a/source/sv/1.0.0/index.html.haml +++ b/source/sv/1.0.0/index.html.haml @@ -174,8 +174,7 @@ version: 1.0.0 %aside Det finns mer. Hjälp mig att samla dessa antimönster genom att - = link_to "skapa ett issue", "#issues" - eller en pull requests + #{link_to "skapa ett issue", "#issues"} eller en pull requests .frequently-asked-questions %h3#frequently-asked-questions From 56cec3d4f7d6065d3aac596b3de9f6dfd58797a9 Mon Sep 17 00:00:00 2001 From: Olivier Lacan Date: Wed, 21 Jun 2017 13:50:19 +0100 Subject: [PATCH 15/19] Upgrade Haml & middleman This might help us narrow down the issue with sv/1.0.0 --- Gemfile.lock | 83 ++++++++++++++++++++++++++-------------------------- 1 file changed, 42 insertions(+), 41 deletions(-) diff --git a/Gemfile.lock b/Gemfile.lock index 82ee853..a8534db 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -1,16 +1,16 @@ GEM remote: https://rubygems.org/ specs: - activesupport (4.2.7) + activesupport (5.0.4) + concurrent-ruby (~> 1.0, >= 1.0.2) i18n (~> 0.7) - json (~> 1.7, >= 1.7.7) minitest (~> 5.1) - thread_safe (~> 0.3, >= 0.3.4) tzinfo (~> 1.1) - addressable (2.4.0) - autoprefixer-rails (6.7.7.2) + addressable (2.5.1) + public_suffix (~> 2.0, >= 2.0.2) + autoprefixer-rails (7.1.1.2) execjs - backports (3.6.8) + backports (3.8.0) coderay (1.1.1) coffee-script (2.4.1) coffee-script-source @@ -18,9 +18,9 @@ GEM coffee-script-source (1.12.2) compass-import-once (1.0.5) sass (>= 3.2, < 3.5) - concurrent-ruby (1.0.2) + concurrent-ruby (1.0.5) contracts (0.13.0) - dotenv (2.1.1) + dotenv (2.2.1) em-websocket (0.5.1) eventmachine (>= 0.12.9) http_parser.rb (~> 0.6.0) @@ -28,43 +28,42 @@ GEM eventmachine (1.2.0.1) execjs (2.7.0) fast_blank (1.0.0) - fastimage (2.0.0) - addressable (~> 2) - ffi (1.9.14) - haml (4.0.7) + fastimage (2.1.0) + ffi (1.9.18) + haml (5.0.1) + temple (>= 0.8.0) tilt hamster (3.0.0) concurrent-ruby (~> 1.0) - hashie (3.4.4) + hashie (3.5.5) htmlcompressor (0.2.0) http_parser.rb (0.6.0) i18n (0.7.0) - json (1.8.3) - kramdown (1.11.1) + kramdown (1.13.2) listen (3.0.8) rb-fsevent (~> 0.9, >= 0.9.4) rb-inotify (~> 0.9, >= 0.9.7) - memoist (0.14.0) + memoist (0.16.0) method_source (0.8.2) - middleman (4.1.10) + middleman (4.1.14) coffee-script (~> 2.2) compass-import-once (= 1.0.5) haml (>= 4.0.5) kramdown (~> 1.2) - middleman-cli (= 4.1.10) - middleman-core (= 4.1.10) + middleman-cli (= 4.1.14) + middleman-core (= 4.1.14) sass (>= 3.4.0, < 4.0) - middleman-autoprefixer (2.7.0) - autoprefixer-rails (>= 6.3.1, < 7.0.0) + middleman-autoprefixer (2.8.0) + autoprefixer-rails (>= 7.0.1, < 8.0.0) middleman-core (>= 3.3.3) middleman-blog (4.0.1) addressable (~> 2.3) middleman-core (>= 4.0.0) tzinfo (>= 0.3.0) - middleman-cli (4.1.10) + middleman-cli (4.1.14) thor (>= 0.17.0, < 2.0) - middleman-core (4.1.10) - activesupport (~> 4.2) + middleman-core (4.1.14) + activesupport (>= 4.2, < 5.1) addressable (~> 2.3) backports (~> 3.6) bundler (~> 1.1) @@ -81,10 +80,10 @@ GEM memoist (~> 0.14) padrino-helpers (~> 0.13.0) parallel - rack (>= 1.4.5, < 2.0) + rack (>= 1.4.5, < 3) sass (>= 3.4) servolux - tilt (~> 1.4.1) + tilt (~> 2.0) uglifier (~> 3.0) middleman-gh-pages (0.0.3) rake (> 0.9.3) @@ -98,34 +97,36 @@ GEM middleman-syntax (3.0.0) middleman-core (>= 3.2) rouge (~> 2.0) - minitest (5.9.0) - padrino-helpers (0.13.2) + minitest (5.10.2) + padrino-helpers (0.13.3.4) i18n (~> 0.6, >= 0.6.7) - padrino-support (= 0.13.2) + padrino-support (= 0.13.3.4) tilt (>= 1.4.1, < 3) - padrino-support (0.13.2) + padrino-support (0.13.3.4) activesupport (>= 3.1) - parallel (1.9.0) + parallel (1.11.2) pry (0.10.3) coderay (~> 1.1.0) method_source (~> 0.8.1) slop (~> 3.4) - rack (1.6.4) + public_suffix (2.0.5) + rack (2.0.3) rack-livereload (0.3.16) rack rake (10.4.2) - rb-fsevent (0.9.7) - rb-inotify (0.9.7) - ffi (>= 0.5.0) + rb-fsevent (0.9.8) + rb-inotify (0.9.10) + ffi (>= 0.5.0, < 2) redcarpet (3.4.0) rouge (2.0.5) - sass (3.4.22) - servolux (0.12.0) + sass (3.4.24) + servolux (0.13.0) slop (3.6.0) - thor (0.19.1) - thread_safe (0.3.5) - tilt (1.4.1) - tzinfo (1.2.2) + temple (0.8.0) + thor (0.19.4) + thread_safe (0.3.6) + tilt (2.0.7) + tzinfo (1.2.3) thread_safe (~> 0.1) uglifier (3.2.0) execjs (>= 0.3.0, < 3) From 47a93addd03cdb4aa4847edae221f22725d22ae1 Mon Sep 17 00:00:00 2001 From: Olivier Lacan Date: Wed, 21 Jun 2017 13:50:29 +0100 Subject: [PATCH 16/19] Remove unsupported Haml 5 config --- config.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.rb b/config.rb index 6f5f887..d217b5c 100644 --- a/config.rb +++ b/config.rb @@ -187,7 +187,7 @@ configure :build do .txt .woff ]} - set :haml, {ugly: true, attr_wrapper: '"'} + set :haml, { attr_wrapper: '"' } activate :minify_css activate :minify_html do |html| html.remove_quotes = false From 802fbcfea61f30e510b59f7e87ede93519207830 Mon Sep 17 00:00:00 2001 From: Olivier Lacan Date: Wed, 21 Jun 2017 13:52:21 +0100 Subject: [PATCH 17/19] Temporarily remove sv 1.0.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It’s breaking the build process. So until we can figure out what’s wrong with @magol let’s just avoid breaking the whole site. --- source/sv/1.0.0/index.html.haml | 300 -------------------------------- 1 file changed, 300 deletions(-) delete mode 100644 source/sv/1.0.0/index.html.haml diff --git a/source/sv/1.0.0/index.html.haml b/source/sv/1.0.0/index.html.haml deleted file mode 100644 index 8803f09..0000000 --- a/source/sv/1.0.0/index.html.haml +++ /dev/null @@ -1,300 +0,0 @@ ---- -description: Håll en ändringslogg -title: Håll en ändringslogg -language: sv -version: 1.0.0 ---- - -- changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md" -- gemnasium = "https://gemnasium.com/" -- gh = "https://github.com/olivierlacan/keep-a-changelog" -- issues = "https://github.com/olivierlacan/keep-a-changelog/issues" -- semver = "http://semver.org/" -- shields = "http://shields.io/" -- thechangelog = "http://5by5.tv/changelog/127" -- vandamme = "https://github.com/tech-angels/vandamme/" -- iso = "http://www.iso.org/iso/home/standards/iso8601.htm" -- ghr = "https://help.github.com/articles/creating-releases/" - -.header - .title - %h1 Håll en ändringslogg - %h2 Låt inte dina vänner slänga in git-loggar i ändringsloggar. - - = link_to changelog do - Version - %strong= current_page.metadata[:page][:version] - - %pre.changelog= File.read("CHANGELOG.md") - -.answers - %h3#what - %a.anchor{ href: "#what", aria_hidden: "true" } - Vad är en ändringslogg? - - %p - En ändringslogg är en fil innehållandes en sammanfattad, kronologiskt ordnad - lista över viktiga ändringar för varje version av ett projekt. - - %h3#why - %a.anchor{ href: "#why", aria_hidden: "true" } - Vad är meningen med en ändringslogg? - - %p - För att göra det enklare för användare och medarbetare att se exakt vilka - viktiga ändringar som har gjorts mellan varje utgåva (eller version) av projektet. - - %h3#who - %a.anchor{ href: "#who", aria_hidden: "true" } - Vem behöver en ändringslogg? - - %p - Alla behöver det. Oavsett om det är användare eller utvecklare, är - alla slutanvändare av mjukvaran människor som bryr sig vad som finns - i mjukvaran. När mjukvaran förändras vill folk veta varför och hur. - -.good-practices - %h3#how - %a.anchor{ href: "#how", aria_hidden: "true" } - Hur gör jag en bra ändringslogg? - - %h4#principles - %a.anchor{ href: "#principles", aria_hidden: "true" } - Riktlinjer - - %ul - %li - Ändringsloggar är för människor, inte maskiner. - %li - Det bör finnas en post för varje enskild version. - %li - Samma typ av ändringar bör grupperas. - %li - Det bör vara möjligt att länka till versioner och sektioner. - %li - Senaste versionen kommer först. - %li - Datum då respektive version släpptes ska visas. - %li - Notering att du följer #{link_to "Semantisk versionshantering", semver}. - - %a.anchor{ href: "#types", aria_hidden: "true" } - %h4#types Typer av ändringar - - %ul - %li - %code Added - för nya funktioner. - %li - %code Changed - för ändringar på existerande funktionalitet. - %li - %code Deprecated - för funktionalitet som snart tas bort. - %li - %code Removed - för nu borttagen funktionalitet. - %li - %code Fixed - för alla buggfixar - %li - %code Security - i fall av sårbarheter. - -.effort - - %h3#effort - %a.anchor{ href: "#effort", aria_hidden: "true" } - Hur kan jag minimera den insats som krävs för att underhålla en ändringslogg? - - %p - Ha en sektion kallad Unreleased högst upp för att hålla reda på - kommande ändringar. - - %p Detta tjänar två syften: - - %ul - %li - Folk kan se vilka ändringar de kan förvänta sig i kommande utgåvor - %li - Vid lansering behöver du bara flytta innehållet i sektionen - Unreleased till en ny versionspost. - -.bad-practices - %h3#bad-practices - %a.anchor{ href: "#bad-practices", aria_hidden: "true" } - Kan ändringsloggar vara dåliga? - - %p Ja, här är några exempel på då de är mindre användbara. - - %h4#log-diffs - %a.anchor{ href: "#log-diffs", aria_hidden: "true" } - Diffar från incheckningsloggen. - - %p - Det är en dålig idé att använda incheckningsloggen som ändringslogg: - de är fulla av brus. Saker så som merge-incheckningar, incheckningar med - otydliga titlar, dokumentationsförändringar etc. - - %p - Syftet med en incheckning är att dokumentera ett steg i utvecklingen av - källkoden. Vissa projekt städar upp bland incheckningarna, andra inte. - - %p - Syftet med en post i en ändringslogg är att dokumentera den noterbara - skillnaden, oftast över flera incheckningar, för att kommunicera dessa - tydligt till slutanvändaren. - - %h4#ignoring-deprecations - %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" } - Ignorera föråldrad funktionalitet (deprecations) - - %p - När användare uppgraderar från en version till en annan, ska det vara - smärtsamt uppenbart när något förväntas gå sönder. Den bör vara möjligt - att uppgradera till en version som listar föråldrad funktionalitet, ta - bort dessa beroenden i sitt program, och sedan uppgradera till en version - där den föråldrade funktionaliteten är borttagen. - - %p - Om du inte gör något annat, lista åtminstone föråldrad och borttagen - funktionalitet samt förstörande förändringar i din ändringslogg. - - %h4#confusing-dates - %a.anchor{ href: "#confusing-dates", aria_hidden: "true" } - Förvillande datum - - %p - I USA lägger folk månaden först (06-02-2012 för 2:a juni 2012), - medan många andra runt om i världen skriver 2 June 2012 men - uttalar det annorlunda. 2012-06-02 fungerar logiskt från störst - till minst, överlappar inte på något tvetydligt sätt med andra datumformat, - och är en #{link_to "ISO-standard", iso}. Dessutom är det rekommenderat - datumformat för ändringsloggar. - - %aside - Det finns mer. Hjälp mig att samla dessa antimönster genom att - #{link_to "skapa ett issue", "#issues"} eller en pull requests - -.frequently-asked-questions - %h3#frequently-asked-questions - %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" } - Vanliga frågor - - %h4#standard - %a.anchor{ href: "#standard", aria_hidden: "true" } - Finns det ett standardformat på ändringsloggar? - - %p - Inte riktigt. GNU:s stilguide för ändringsloggar och den två stycke - långa GNU NEWS-filen med riktlinjer finns. Båda är bristfälliga och - otillräckliga. - - %p - Detta projekt har som mål att bli - = link_to "en bättre konvention för ändringsloggar.", changelog - Det utgår från uppenbart goda praxis från öppen källkods-världen och sammanför dem. - - %p - Konstruktiv kritik, diskussion och förslag till förbättring - = link_to "är välkommen.", issues - - %h4#filename - %a.anchor{ href: "#filename", aria_hidden: "true" } - Vad bör filen med ändringsloggen heta? - - %p - Döp den till CHANGELOG.md. En del projekt använder - HISTORY, NEWS eller RELEASES. - - %p - Även om det är lätt att tänka att det inte spelar så stor roll vad filen - med ändringsloggar kallas, varför göra det svårare för dina slutanvändare - att enkelt hitta de viktigaste ändringarna? - - %h4#github-releases - %a.anchor{ href: "#github-releases", aria_hidden: "true" } - Hur är det med GitHub Releases? - - %p - Det är ett fantasiskt initiativ. #{link_to "Releases", ghr} kan användas - för att göra enkla git-taggar (t.ex. en tagg kallad v1.0.0) - till formaterade versionsanteckningar genom att manuellt lägga till - versionsanteckningar eller så kan den hämta meddelandena i kommenterade - git-taggar och omvandla dessa till versionsanteckningar. - - %p - GitHub Releases skapar en icke porterbar ändringslogg som enbart kan visas - för användare på GitHub. Det är möjligt att formatera det ungefär som på - Håll en ändringslogg-formatet, men det tendera att bli lite mer invecklat. - - %p - Nuvarande version av GitHub releases är möjligtvis också lite svår att - hitta för slutanvändare, till skillnad från filer med normalt stora - bokstäver (README, CONTRIBUTING, etc.). - Ett annat bekymmer är att användargränssnittet för närvarande inte - erbjuder länkar till incheckningsloggar mellan olika versioner. - - %h4#automatic - %a.anchor{ href: "#automatic", aria_hidden: "true" } - Kan ändringsloggar bli automatiskt tolkade? - - %p - Det är svårt då människor följer vitt olika format och filnamn. - - %p - #{link_to "Vandamme", vandamme} är en Ruby gem skapad av gruppen - #{link_to "Gemnasium", gemnasium} som tolkar många (men inte alla) - ändringsloggar för öppen källkod. - - %h4#yanked - %a.anchor{ href: "#yanked", aria_hidden: "true" } - Hur är det med brådskande utgåvor ("yanked")? - - %p - Brådskande utgåvor är versioner som måste släppas på grund av alvarliga - buggar eller säkerhetsproblem. Oftast brukar dessa versioner inte ens - finnas med i ändringsloggarna. De borde det. Så här borde du visa dem: - - %p ## 0.0.5 - 2014-12-13 [YANKED] - - %p - Taggen [YANKED] står ut av en anledning, det är viktigt - att folk se det. Då den är omsluten med hakparenteser är det också lättare - för ett program att tolka det. - - %h4#rewrite - %a.anchor{ href: "#rewrite", aria_hidden: "true" } - Borde du någonsin förändra en ändringslogg? - - %p - Självklart. Det finns alltid en bra anledning att förbättra en ändringslogg. - Jag öppnar regelbundet pull requests för att lägga till saknade utgåvor - för öppna källkodsprojekt som inte tar hand om sin ändringslogg. - - %p - Det kan också hända att du upptäcker att du glömt att ta upp en icke - bakåtkompatibel förändring i en version. I sådana fall är det självklart - viktigt att uppdatera din ändringslogg. - - %h4#contribute - %a.anchor{ href: "#contribute", aria_hidden: "true" } - Hur kan jag bidra? - - %p - Detta dokument är inte sanningen, det är en noga övervägd - åsikt tillsammans med information och exempel jag har samlat på mig. - - %p - Detta beror på att jag vill att vår gemenskap ska nå enighet. Jag tror på - att diskussionen är lika viktig som slutresultatet. - - %p - Så tveka inte att #{link_to "kasta dig in i diskussionen", gh}. - -.press - %h3 Samtal - %p - Jag var med i #{link_to "The Changelog podcast", thechangelog} - för att prata om varför förvaltare och bidragsgivare bör bry sig om - ändringsloggar, och motiveringen bakom detta projekt. From dc6833e9115f7cb61de753b928781c30b2937958 Mon Sep 17 00:00:00 2001 From: Olivier Lacan Date: Wed, 21 Jun 2017 14:24:03 +0100 Subject: [PATCH 18/19] Fix JS bug in FAQ --- source/assets/javascripts/all.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/assets/javascripts/all.js b/source/assets/javascripts/all.js index bec14c6..e84aec9 100644 --- a/source/assets/javascripts/all.js +++ b/source/assets/javascripts/all.js @@ -21,7 +21,7 @@ document.addEventListener("DOMContentLoaded", function(){ paragraphs = []; paragraphs.push(lastParagraph); - while (lastParagraph.nextElementSibling.tagName == "P") { + while (lastParagraph.nextElementSibling && lastParagraph.nextElementSibling.tagName == "P") { lastParagraph = lastParagraph.nextElementSibling; paragraphs.push(lastParagraph) } From 1305ed08db8d58d5d482f1074ee0b875d9877046 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Magnus=20=C3=96sterlund?= Date: Wed, 21 Jun 2017 22:49:15 +0200 Subject: [PATCH 19/19] sv/1.0.0 - Fix UTF-8 BOM --- source/sv/1.0.0/index.html.haml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/sv/1.0.0/index.html.haml b/source/sv/1.0.0/index.html.haml index 075736b..aeb27c7 100644 --- a/source/sv/1.0.0/index.html.haml +++ b/source/sv/1.0.0/index.html.haml @@ -1,4 +1,4 @@ ---- +--- description: Håll en ändringslogg title: Håll en ändringslogg language: sv