Will there be any issues with my current metadata file if I switch to a version number model I've been thinking about?

[zikalify]

So I’m currently on version 0.9.0 of my app and have been thinking that I might adjust it to year.day_of_the_year.revision_that_day, so for example, if I had made a new version today I’d put 2018.284.1 and then if I wanted to do another change that day I could go 2018.284.2

If I was to adopt this, does my current metadata file look like it would handle it ok? I’m concerned about whether this bit will understand the new model:
Auto Update Mode:Version %v
Update Check Mode:Tags ^[0-9.]+$

[Coffee]

I can’t say if the metadata is correct, but as long as you don’t decrease your VersionCode, things should be mostly fine.

As for me, please consider Semantic Versioning or something similar. I can’t make sense of your versioning scheme. When I make my first selection from the list of apps to consider for twif, and I see your app updated from, let’s say, 2018.284.1 to 2018.296.1, I’ll most likely ignore your update and favor something that updated from 1.1.4 to 1.3.0, and I will definitely look into any app that goes from 1.5.16 to 2.0.0.

[hans]

That git tag scheme should work fine.

[TPS]

@Coffee

When I make my first selection from the list of apps to consider for twif, and I see your app updated from, let’s say, 2018.284.1 to 2018.296.1 , I’ll most likely ignore your update and favor something that updated from 1.1.4 to 1.3.0 , and I will definitely look into any app that goes from 1.5.16 to 2.0.0 .

@zikalify So, append the new date-code as a suffix to the previous versioning, so you get easy visual scanning (as @Coffee notes) & your dates are obvious, too.

E.g.: 1.3.0.2018.285.1, then 1.4.2.2018.291.3, &c.
(@Coffee I believe that @zikalify wants to use

@zikalify

year.day-of-the-year.revision-that-day

for whatever reason. )

Or are you trying to keep solely xxx.yyy.zzz scheme, for some reason?

[zikalify]

I’m keeping the current version scheme atm which honestly doesn’t mean much lol, I’m just working my way up by one on the end column till I get to 9 then iterate the second bullet point lol so 0.8.9 > 0.9.0 etc. I just thought about using the date because honestly I don’t think the system I’m using right now make much sense at least with using a date it gives me some tangible information - that was all that I was thinking about it for.

[Licaon_Kter]

Why do you need such fine details regarding the build?

[Coffee]

@TPS

Or are you trying to keep solely xxx . yyy . zzz scheme, for some reason?

Just trying to explain that the consequence of the chosen versioning scheme means they won’t be featured in twif.

(Unless someone wants to whisper in my ear when a cool new feature lands in the app )

[TPS]

@Coffee Nono, I was just asking whether @zikalify had any necessity for xxx.yyy.zzz (just 3 divisions) or whether major.minor.revision.year.day-of-the-year.revision-that-day would be functional for the workflow.

[zikalify]

I was just thinking about it because the current numbering system I’m using doesn’t really mean anything at least by using the date I can see when I pushed it to github a bit more easily.

[TPS]

• It works better for your workflow.
• Other folks (users/reviewers) find it harder to scan.
• The scheme I proposed would maximize both, as most folks (IMHO) really stop after major.minor(.blah.blahblah).
• I doubt software would care, just as long as the version # consistently increments, as @Coffee mentioned:

@Coffee

as long as you don’t decrease your VersionCode, things should be mostly fine.

@zikalify Btw, there’s extensive info @ Wikipedia that may help you decide:

Software versioning