From b0dc490911877bd0d60005e931622f91b7b55b8a Mon Sep 17 00:00:00 2001 From: Christian Schabesberger Date: Wed, 20 Feb 2019 22:33:27 +0100 Subject: [PATCH] add first 4 steps of releasing a NewPipe version --- assets/feature_branch.dia | Bin 0 -> 1427 bytes assets/release_branch.dia | Bin 1353 -> 0 bytes docs/05_releasing.md | 47 ++++++++++++++- ...{release_branch.svg => feature_branch.svg} | 56 ++++++++++++------ 4 files changed, 83 insertions(+), 20 deletions(-) create mode 100644 assets/feature_branch.dia delete mode 100644 assets/release_branch.dia rename docs/img/{release_branch.svg => feature_branch.svg} (74%) diff --git a/assets/feature_branch.dia b/assets/feature_branch.dia new file mode 100644 index 0000000000000000000000000000000000000000..8712d6394b45026303a61548e9e48956429e95e6 GIT binary patch literal 1427 zcmV;E1#J2siwFP!000021MOPfZ>u&GfA3#`=xam3K!DquUTu@MJxto9-91MJ9O7Na zM8-*)KJ0Iw4fH1ABLoOtI}xd^a1Q5ZAI|xm5BmAb^O`6-#1b6SxoT*-svsJ~A*Rt> z{p;(`6IcE6boV*L@RRt77+fpj4w}fTxw_(f^JzNW@An!xB#_5UBY3MNX!;K%1Wtv} zRDHTrlv4#E>!z|_sjgFPIE=m zGffw?Z(xLchTyk)<+}KIUN_|%#EOd7n>fKjgda8~ks3Yn_lZm{l?WjkJ>CCc-Dg|M z7mm8BHd+h9*N{b+mT`o2NM;J4xc~rR4%>4*-LV|w)h6xX{I`W8ZwtrX77iziP0Toh zn3o~_I3@_v43)Dj>W-5HkO&vMbgUkySYpoOhW#%gNv=6Sw){QX+D2}~aCkXz&m?NJ zga`2#2ZKJ6Jr4P5@jTEY$+RB^(!Rq9_6e%mJ*NC->JPV3U-W=9M;veO>2aC1+9VXZ z$VPUTBou9Nh>`|pK9{M{w93V%O?EHJ^)yY0lMR7~%SR{*)#!qhW5HoCLE(*W5S#3Edi+dy9HirG@3LQPSHlOdMx z^jEPl#3Ck(QzfUHd@D+R0C=(l#d&tGS0@giJ-OVG|KyN{kcG-b`HG&odQy$63J&M$ z@A`Qp6wN2JiE5w}&8Zc0((^RWey}yucI;x5mMvC?;rm4hCeKSFf=*#9&6xrF5g3|b z0*PuH-7vYdMgu1oWa=C&EtJpX3N>|zb~Q!y1!t}+Yhuc)u;jY36a@k~h%G^ys7k^Q z(pyB+mHQVWJH&ASPd&T+4ps<9tI9nb)3~m=`uWG|2YT*;*SldCtn=h~p^ww`V+!pC zC6Y%(*QolDBD!7Y=DZT6l8@TO#V*}aF*1%@F&n}yTg*79j+A~u@fwM{0>MguAhwj> z{DfIRPz663H{d7JelT?59zzopNO4?&BN@sSSEgolMin-KO%xSkk)%6mM+B`GLCk1* zVsKmIr9f%vUpC;eeYMWm0vJ88N(40!m}p*6)4_DjC=g*EFiAjLR`!WYwA2PuQUVJbD3UhJ}Mj0Ru&|9vslFpzleMc$;HDJD)rVdf+}S; z9}Fbf`f@~r)Xqk_CK;SmsK1G4c9H?~JOhBf835>-opSNOC91$N9LG(O^qKo8u3gic zJs6G#bQg3(mX-ek(XiCFTzSfBLAfWRvo%Bn1)Jhls-_^VxSNIx$XL9u57@q%7X;Dh zGF{t!AsQ3Hl?ca{H7QZ?>o>|u#7M((3&37>>HuB<_O=N z7@F;XAtN-$0h%!rHQIMn3%vg(a_k_7?jUQNaBLypVGG&JNmlQw0cf5JJULRB>6SHQ z-H;>6;g)S#k6@-by5ptOE#O)2pPQBl@-0J)=flfLQ$y2KtzV8r_0eZtc5luyWe+eL zywQyPLK zBUUr+n)OZsqK-6xWaOC(2A+2T6Ic=mIF9oufoBfr_qxDGFN@|`SIrSCCGGSDhN(AB z#b!dEb;af3I0RoipBOI_KPgP;~if-58Qf zQVbESy8ZZy2kfr&H4f(fR~>KJ|HfYTLk{KK-c%%6LAt`AbxjH)3x~A3O#w}Ppj! literal 0 HcmV?d00001 diff --git a/assets/release_branch.dia b/assets/release_branch.dia deleted file mode 100644 index 149a9d4d3ab25b5d5a7a9cd0c14da4a7ee0351ba..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 1353 zcmV-P1-AMhiwFP!000021MON%Z{s!)zUNm6%GIVN>gmloi?%@9LxC3P_AJm6Ewf8g z21VO(4*l&VC1q{vVOf?HWC0sU0#T#+$kEI<59jljmlf5vn5QIRGu;G+u3;7?5n=I6 z|L5zkV_*OB{O~y<=#%`3Ia+D*36`p>nZ6Wa{b@4U?RJ3fQzQ}&DA|A%PyR!cqKOom z=+6(DcB~*m0;#oP6$!z~d?T>N&0)R#RV%MpjidwN{1tuYBj zK6bEkO%jSXB*JNnGoQ*dXj&FxlQz4T<$9VXBI%l<{rMx5g&K4rCWz!Pl;Y?{Ow&Y_ z46Vl^8JBosK%`{;FAfLh|7Ehf2@}TTaby`fUMDhK)7wB^>WcYNsY1l%q> z`k%&WB$Ul3waIFr63v+v3(}i{sWWnb<#pS(=8SxM8}@peFsZS;$`g~4r$x~zH$1o`+=Ui;N@<34c2M$Jk!S+#vz4X z2PKn7%vQMmm14G873RDUrIwGn#l<$;QaLgXTd`WgEnmzzsEL$*!^sNEr$Wg}e__5* zcYYx}q_~Ek%p35N<%~>2y2sE21v4C9;wXml<&_2Ot5KzmP#Z->L?-F0v}1}_L6~q> zofzEKco|Su`d1BjXkYCUwt!|2tO`L51SXqT+;%Vnm?a|Y1EvUQ!>c}Vj+VNBEC{6+ zfRqPh-9S`97Szn)+Uu~+_R2C~GnW~a=A*U|?PNhp*1QeI2jiYT%t-G)ARfc$#DHAdF@+M zcVv118a})ZSylc4W>KYYx$ue?Py^;KYjbuAB*}ZEA3#h4r zZ46sEC=?s`rkZVeAfIfxAD@o6Y`9R0gO~m5otcJardn6L^U{w#;Bsz3QO?L6yt`4e zEC~a%@s-jB6o{9qH6=|24t-W_2tG(}7&1oE~H9u?BkL1kGBf0!K`$v)Ihm-##d4BjG L2p@G|Vl4mwmMfXh diff --git a/docs/05_releasing.md b/docs/05_releasing.md index 3807f10..16b8e8d 100644 --- a/docs/05_releasing.md +++ b/docs/05_releasing.md @@ -26,9 +26,9 @@ For development the __dev__ branch is used. Pushing to __dev__ directly however This ensures that also the dev version works as good a possible. So in order to change something on the app one may want to __fork__ the dev branch and develop the changes in his own branch (this is called feature branching). -![feature_branching](img/release_branch.svg) +![feature_branching](img/feature_branch.svg) -### Merching features/bugfixes +### Merging features/bugfixes After being done with the feature one should open up a __Pull Reuqest__ to the dev branch here a maintainer can do __Code review__ and __Quality Assurance (QA)__. If you are a maintainer please take care about the code architecture so corrosion or code shifting can be prevented. Please also preface core quality over functionality. @@ -36,10 +36,19 @@ So in short: cool function but bad code -> no merge. We should focus on leaving ![merge_feature_into_dev](img/merge_into_dev.svg) -At best you as a maintainer should build the app and put the signed apk into the description of that new Pullrequest. This way other people can test the feature/bugfix and therefore help with QA. +At best you as a maintainer should build the app and put the signed apk into the description of that new pullrequest. This way other people can test the feature/bugfix and therefore help with QA. + +After the maintainer merged the new feature into the dev branch he should add the title of the pullrequest or a summary of the changes into the [release note](#release-notes). ### Creating a new release +Once there are enough features together, and the maintainer feels like releasing he should create a new release. Here is a list of things he will want to do then. + +1. Fork the __dev__ branch into a new __release_x.y.z__ branch. +2. Increase the [version number](#versioning) +3. Copy the [release note](#release-notes) from the github version draft into the corresponding fastlane file (see [release note](#release-notes)). +4. Open up a pull request form the new __release_x.y.z__ branch into the __master__ branch. + ### Releasing ## Hotfix releases @@ -49,3 +58,35 @@ At best you as a maintainer should build the app and put the signed apk into the ### Fix branch ### Releasing + +## Versioning + +Versioning NewPipe is simple. + +- __Major__: The __major__ version number (the number before the first dot) was 0 for years. The reason for this changed over time. First I wanted this number to + switch to 1 once NewPipe was feature complete. Now I rather think of increasing this number to 1 once we can ensure that NewPipe runs stable (part of which this documentation should help). After this (2 and beyond) well god knows what happens if we ever reach 1 ¯\\\_(ツ)\_/¯ . +- __Minor__: The __minor__ version number (the number after the first dot) will be increased if there is a major feature added to the app. +- __Small Minor__: The small minor (the number after the second dot) will be increased if there are just smaller bug fixes or features added to the app. + + +#### Versioning the extractor + +The extractor is always released together with the app, therefore the version number of the extractor is the same as the one of the app. + +#### Version code +In android an app can also have a [versionCode](https://developer.android.com/studio/publish/versioning). This code is a `long integer` and can be increased by any value to show a device that a new version is there. +For NewPipe the version code will be increased by 10 regardless of the change of the major or minor version number. The version codes between the 10 steps +are reserved for our internal fdroid build server. + +## Release notes +Release notes should give the user an idea of what was changed on the app. The release nodes for NewPipe are stored in the [github draft for a new release](https://github.com/TeamNewPipe/NewPipe/releases/tag/v0.14.0). When a maintainer wants to add change to the release note, but there is no draft for a new version he should create one. + +Changes can be categorized into three types. + +- __New__: New features that god added to the app. +- __Improved__: Improvements to the app, or already existing features +- __Fixes__: Bugfixes + +When releasing a new version of NewPipe, before actually hitting release the maintainer should copy the release note from the draft and put it into a file called +`.txt` (whereas `` needs to be the version code of the comming release). This file must be stored in the direcotry [`/fastlane/metadata/android/en-US/changelogs`](https://github.com/teamnewpipe/newpipe/tree/dev/fastlane/metadata/android/en-US/changelogs). This way fdroid will later be able to show the +changes done on the app. diff --git a/docs/img/release_branch.svg b/docs/img/feature_branch.svg similarity index 74% rename from docs/img/release_branch.svg rename to docs/img/feature_branch.svg index ba3c833..7858eec 100644 --- a/docs/img/release_branch.svg +++ b/docs/img/feature_branch.svg @@ -8,14 +8,14 @@ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" width="210" - height="310.22198" - viewBox="385 95 111.125 157.21394" + height="300" + viewBox="385 95 104.17968 152.03365" version="1.1" - id="svg31" - sodipodi:docname="release_branch.svg" + id="svg39" + sodipodi:docname="feature_branch.svg" inkscape:version="0.92.3 (2405546, 2018-03-11)"> + id="metadata45"> @@ -27,7 +27,7 @@ + id="defs43" /> + inkscape:current-layer="svg39" /> + transform="matrix(0.6187154,0,0,0.6187154,144.56047,34.721636)"> release_xyz + x="459.65701" + y="107.209" + id="tspan18">feature_xyz + + + + + +