Versioning is inconstistent #11
Comments
|
I think we should first investigate onto the Niantic versioning, before we change to |
|
It seems to me that the I say this because we've seen cases where the This repository's purpose is to serve as an archive of As far as backwards-compatibility goes, maybe the way forward is to create a branch to use this new naming convention. We could either maintain both branches, or deprecate the current system and only add new files to the new system. I don't know about others, but I'm using this repository as a |
|
There are absolutely more game master versions than app versions. Niantic
versions by week and then day. The numbers don't add up because I guessed
what the numbers are. The fact that noone knows what the numbers should be
suggests we should change to YYYYMMDD and be done with it.
…On Wed, Jul 4, 2018 at 2:19 AM, Dominic Barnes ***@***.***> wrote:
It seems to me that the GAME_MASTER is a separate entity from the app
itself, which makes the current version naming/convention inaccurate.
I say this because we've seen cases where the GAME_MASTER is updated
multiple times between app versions, such as at the beginning and end of
events. In addition, the opposite is also true where app versions come out
with no change to the GAME_MASTER, only to make bug fixes in the game's
code.
This repository's purpose is to serve as an archive of GAME_MASTER files
over time. As such, I believe that using dates (eg: YYYYMMDD) makes the
most sense to me. As a nice side-effect, this change would eliminate a
manual step for importing new files (ie: no longer manually defining a
version, and relying on mtime instead).
As far as backwards-compatibility goes, maybe the way forward is to create
a branch to use this new naming convention. We could either maintain both
branches, or deprecate the current system and only add new files to the new
system.
I don't know about others, but I'm using this repository as a git
submodule in my own project
<https://github.com/dominicbarnes/pokemongo-api> rather than the npm
package. I just list the folders in the versions/ directory and sort them
via semver, and changing to sort by "YYYYMMDD" would be trivial for me.
(curious to hear about others)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAX4gN2lx_od8UICHFKt1zGQ7bfAt-dwks5uDIiggaJpZM4VCKry>
.
|
|
@celandro I’m just cautious, because I do not want to break dependants applications. But it seems like it is the best way using a timestamp. From where do we decide the What about the existing versions? Should we change the version numbers to timestamps so it is consistent? I’m currently kinda busy and sometimes in holidays in the next 2-3 weeks. I’ll follow the discussion but do not know if I can code (update test cases for example). |
|
I think Timestampms is from when it is downloaded. It will be the correct
date in most cases historically as I update the day of any change.
Changing the script to be a docker command is definitely recommended. I can
probably update the java code to do all the naming pretty easily,
especially if we use the timestamp.
One other issue is sometimes there are multiple updates same day. Perhaps
we should do Yyyymmddhhmmss instead.
I'm up for whatever but the directory names should be automatically named
from the timestamp.
…On Wed, Jul 4, 2018, 2:03 PM BRUNNEL6 ***@***.***> wrote:
@celandro <https://github.com/celandro> I’m just cautious, because I do
not want to break dependants applications. But it seems like it is the best
way using a timestamp.
From where do we decide the YYYYMMDD format? Should it be the release
date of the GAME_MASTER file? So the timestampMsproperty basically, or am
I getting this wrong?
What about the existing versions? Should we change the version numbers to
timestamps so it is consistent?
I’m currently kinda busy and sometimes in holidays in the next 2-3 weeks.
I’ll follow the discussion but do not know if I can code (update test cases
for example).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAX4gBTIWBogKj10sU_AltjnN-pLTIDfks5uDS26gaJpZM4VCKry>
.
|
|
I'm fine with YYYYMMDD-HHMMSS (or whatever) as a format regardless of the source of the timestampMs (canonical or download time). I agree we should just do it and move on -- as long as we have an easy to reason about versioning scheme that doesn't confuse we should be fine. No need to 🚲 shed it for too long. I'm indifferent on renaming versions but I'm slightly inclined to keep the old version numbers and do this going forward, looks like a natural sort would keep them in order anyway. If someone wants consistency I won't argue though. |
|
Started a new branch. Feel free to contribute #12 |
@dominicbarnes and people from Twitter pointed out, that the upcoming version from the PR #10 and GAME_MASTER 0.108.3 seems to be inconsistent with the actual versioning.
More infos about the APK versioning, look here:
https://www.apkmirror.com/apk/niantic-inc/pokemon-go/
The current discussion is, whether this repository should switch to dates (e.g.
YYYYMMDD) as identifier rather than the version name of a GAME_MASTER file.The text was updated successfully, but these errors were encountered: