[01:28:27] *** Quits: Horwitz (~mich1@p200300ec9f062d00022268fffe64e7c4.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) [01:40:58] *** Joins: Horwitz (~mich1@p200300ec9f028e00022268fffe64e7c4.dip0.t-ipconnect.de) [01:40:58] *** ChanServ sets mode: +o Horwitz [08:26:26] Failed: build (#22524; push) in navit-gps/navit (pull/987) -- https://circleci.com/gh/navit-gps/navit/22524?utm_campaign=chatroom-integration&utm_medium=referral&utm_source=irc [09:24:19] Failed: jkoan's build (#22526; push) in navit-gps/navit (trunk) -- https://circleci.com/gh/navit-gps/navit/22526?utm_campaign=chatroom-integration&utm_medium=referral&utm_source=irc [12:33:03] Failed: jkoan's build (#22541; push) in navit-gps/navit (trunk) -- https://circleci.com/gh/navit-gps/navit/22541?utm_campaign=chatroom-integration&utm_medium=referral&utm_source=irc [13:53:03] Failed: jkoan's build (#22558; push) in navit-gps/navit (master) -- https://circleci.com/gh/navit-gps/navit/22558?utm_campaign=chatroom-integration&utm_medium=referral&utm_source=irc [14:36:13] @ilovekiruna, we got a bit problem with our android app, and probably you could help me by thinking with me. [14:38:06] sure @jkoan [14:38:19] do you want to discuss here or PM? [14:38:46] here would be good as its interesting to others as well [14:39:05] ok :-) [14:39:07] currently our VersionCode has the format of: yyMMddHHmm [14:40:00] now i just found out that 2100000000 is the maximum allowed versioncode by Google Play as pointed out here: https://developer.android.com/studio/publish/versioning.html [14:40:15] an 2021 now breakes this limitation [14:41:33] another Problem is that we cant just downgrade the currenly used number by removing the last digit because the versioncode needs to be always incremented [14:42:46] I slowly see the problem [14:42:58] what is the current number? [14:43:40] so we need to find some scheme which fits between 2012201504 and 2100000000 and at best is also some sort of timestamp [14:45:38] my current idea would be to do this format: 20yyMMddHH this would break at 2099 probably enough but has the real downside that that we can only have one update per hour [14:46:12] how often do we have updates? [14:46:26] I thought generally a lot less frequent than one hour [14:46:31] or am i wrong? [14:46:43] on every push to master [14:46:57] we also need to account for nightly build [14:47:39] are we pushing to master directly? [14:47:51] I thought most of our things anyway go through PRs [14:48:21] not directly but if all builds to trunk are passed its merged automatically [14:50:54] An alternative to this would be real nightly builds one each day [14:57:56] For example I committed something to trunk today to fix the circleci build that was merged to master and resulted in the (first in 2021) upload to Google play [15:05:26] actually I like this idea, of just one a [15:05:30] upload a day [15:05:32] as nightly [15:06:16] are the things you upload to Google play directly in the main channel so to speak or in the beta channel? [15:24:27] It's beta [15:25:06] But main uses the same format [15:25:44] But even with one upload per day the Problem this exists what format to use [15:34:17] question was related to the fact, that I should be on the beta channel [15:34:31] just dont seem to receive very frequent updates ;-) [15:35:37] isnt your foramt simply yyyyMMddHH? [15:35:41] or did i miss something [15:35:48] i mean your suggestion [16:03:31] But prepended with 20 because we can't downgrade the versioncode [16:25:02] i mean 20 will anyway be the beginning of the 4 digit year number for the next 79 years ;-) [16:25:42] and by then I guess both of use will have other worries ;-) [16:28:46] Ah yes, your correct [16:31:35] just one thing in the discussion I did not understand completely [16:31:58] i think the idea is nice, do you want only comments from me or also some alternative suggestions? [16:33:14] As we need to find a solution before we can push to Google play again I would open a pr but only give it this weekend until merging [16:45:08] sounds good [16:45:12] I can also comment there again [19:51:10] @ilovekiruna another possible idea would be unix timestamp / 10 which would run out in year 2635 [19:52:37] ah no, forget it, this would be 161013549 for now which is less than the current one