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


#1

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.]+$


#2

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.


#3

That git tag scheme should work fine.


#4

@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

for whatever reason. :man_shrugging:)

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


#5

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.


#6

Why do you need such fine details regarding the build?


#7

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 :wink: )


#8

@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.


#9

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.


#10
  • 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:

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