Skip to content

Commit

Permalink
iOS: preventing leading zeroes in month for bundle version as well
Browse files Browse the repository at this point in the history 
#199
  • Loading branch information
@Shchvova
Shchvova committed Dec 3, 2020
1 parent d831598 commit a365b4c
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion platform/resources/CoronaPListSupport.lua
View file
Expand Up @@ -215,7 +215,7 @@ function CoronaPListSupport.modifyPlist( options )
-- Apple treats this the build number so, if it hasn't been specified in the build.settings, we
-- set it to the current date and time which is unique for the app and human readable
bundleVersionSource = (infoPlist.CFBundleVersion == "@BUNDLE_VERSION@") and "set by Simulator" or "set by Info.plist"
infoPlist.CFBundleVersion = os.date("%Y.%m.7%d%H%M")
infoPlist.CFBundleVersion = os.date("%Y.7%m.7%d%H%M")
end

local version = options.bundleversion or "1.0.0"
Expand Down

19 comments on commit a365b4c

@Zorfware
Copy link

@Zorfware Zorfware commented on a365b4c Dec 12, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is flawed. It ruins the former logic of yyyy.mm.ddhhmm I now get version 2020.712.7121335 when creating and submitting builds to Apple. Where as I got version 2020.12.101432 in my prior build. Sorry, I don't remember what version of Solar2D I upgraded from. Besides there is nothing wrong with leading zeros in date structures, it makes it easy to parse in backend.

@Shchvova
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, what the problem? Your new build bundle number is higher than previous.

@Shchvova
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #199 for details

@Zorfware
Copy link

@Zorfware Zorfware commented on a365b4c Dec 12, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That you now make the version number a different format, a longer data format, which require changes to database and mess up my login logic and backend. Now I made changes in my build settings to preserve the original way. I read the other case, and will be testing this claim, which hasn't been an issue for 8 years. I use the original format to block previous builds on startup.

@Zorfware
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So are you going to change it to the right format by removing the leading zeros? Or are we going to live with this hack for ever?

@Shchvova
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m very sorry. I can’t change it now. Because then new builds would have numerically smaller bundle version than 7xx builds.

@Shchvova
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For your specific case I suggest you your dynamically generated string into your build settings or drop leading 7s. You can’t have month or day in 7 hundreds.

@Zorfware
Copy link

@Zorfware Zorfware commented on a365b4c Dec 13, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my specific case? It's the best case for everyone to drop the your 7 and the leading zero. And you can fix it! You can just make a clause (year>2020) for the year 2021 to change and revert and fix it the right way in in builds made after New Years. Because coming new year the major version number will be the dominant factor for version control.

@Zorfware
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here you go. A demo to fix for the hack. Next year you can simplify it, when the 7 hack become obsolete, because everyone will build 2021 versions.

local futuredate = os.time()+5000000
local version = os.date("%Y.7%m.7%d%H%M",futuredate)
print(version) -- hack build number
if tonumber(os.date("%Y",futuredate)) > 2020 then
local datedata = os.date( "*t", futuredate)
version = datedata.year .. '.' .. datedata.month.."." .. datedata.day .. os.date("%H%M",futuredate)
end
print(version) -- future build number

@Zorfware
Copy link

@Zorfware Zorfware commented on a365b4c Dec 13, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Next years code will simply be
local datedata = os.date( "*t")
infoPlist.CFBundleVersion = datedata.year .. '.' .. datedata.month.."." .. datedata.day .. os.date("%H%M")

@Zorfware
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But time is of the essence. The later you fix the hack, the less likely people will be update before next year.

@Zorfware
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And now that we're improving everything, why not make it UTC time, so builds made by my colleagues in Australia and USA doesn't make a build number smaller than mine.

local datedata = os.date( "!*t")
infoPlist.CFBundleVersion = datedata.year .. '.' .. datedata.month.."." .. datedata.day .. os.date("%H%M")

@Shchvova
Copy link
Contributor Author

@Shchvova Shchvova commented on a365b4c Dec 13, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry. This won't work. If some users would use older version to build their app in next year than update, it Apple won't accept their updates because bundle version would be lower. It is out of the box now, I can not put it back. Why don't you write same code in your build.settings?

local datedata = os.date( "*t")
settings =
{
   iphone = {
       plist = {
           CFBundleVersion = datedata.year .. '.' .. datedata.month.."." .. datedata.day .. os.date("%H%M"),
      }
   }
}

@Zorfware
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then they can change their CFBundleVersion!!! You got to fix what you ruined! I'm giving up on this platform and sponsering, if bad choices is going to be the dominating factor. I will be afraid of the next choices you make and doubt this platform will become anything but abandonware.

@Shchvova
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From one hand: you have clear work around, which consists of 2 lines of code.
From another, I will break updates for anyone, who used latest versions of Solar2D. Literally people would not be able to update their apps, would face mystical errors from Apple on upload and don't know what to do.

Format of Bundle ID was never documented anywhere, and is not part of any API. I have no idea someone would rely on it. If you want, I can make you a special build, with old style bundle ID and everything else updated, this isn't hard for me and you would be able to continue use the engine. Would you prefer that?

Is there any particular reason you need CFBundleVersion to stay old way?

@Shchvova
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here. In a hour this build will be built: https://github.com/coronalabs/corona/actions/runs/418881292
You can use it and get Bundle Version as you want it.

@Shchvova
Copy link
Contributor Author

@Shchvova Shchvova commented on a365b4c Dec 13, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This got out of hand fast.
I am very sorry this change breaks your assumptions of how Solar2D builds its CFBundleVersion. They never was part of public API or documented anywhere. My suggested solution is to add following 2 lines to the end of your build.settings file:

local datedata = os.date( "*t")
settings.iphone.plist.CFBundleVersion = datedata.year .. '.' .. datedata.month.."." .. datedata.day .. os.date("%H%M")

Alternatively, you can ask me to make you a special build, like this one in case adding 2 lines to build.settings is impossible somehow.
I am sorry for inconvenience, and would love to implement a solution which would not block people from updating their apps.
Thanks

@Shchvova
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am closing this conversation. At this point there is are clear workarounds. If you want a fix, create a pull request which would not break people builds.

@Shchvova
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You always welcome to reach me via my personal email or on Discord

Please sign in to comment.