Skip to content


Add some form of version information to MR #541

tonyarnold opened this Issue · 16 comments

6 participants


Mentioned in #195, @wm-j-ray asked how he could check he’s running the latest version of MR. It’s probably worthwhile having something built-in to both the headers and the framework/library.

@tonyarnold tonyarnold was assigned

Why not using CocoaPods for that? It manages versioning, dependencies and all of that for you. Really simple to use, and provides loads of nice stuff regarding versioning, dependencies and all.

For exemple to include MR, all you have to do is add pod "MagicalRecord" in the Podfile of your project and run pod install to get the latest version and all configured automatically (including the addition of CoreData.framework in your app project for you if not already there).
A lot of other components are available in CocoaPods, like AFNetworking, OHHTTPStubs, ShareKit, TestFlightSDK, … and all can be integrated with a single line added in your Podfile.

Among other things, CocoaPods generates the Podfile.lock file which lists the version of all the components it installs. With pod update it will check for you if you have the latest version of MR, and even install it automatically if the API is compatible.


I use CocoaPods, but it's not for everyone. It's good practice to include some physical record of the library's version in the code itself somewhere (akin to a timestamp).

Just haven't made time to add this yet. /cc @magicalpanda/team-magicalrecord


Yeah I agree but the problem with that is maintenance. There is a high risk that the author forget to update the version number in the headers of its lib and that this information will be out of date thus misleading.


Realistically, that's a problem for Saul, Stephen and I. We'd need to update the headers with each release.


Also, the process for updating our pod spec is just as manual and suffers from the same problems. CocoaPods fixes nothing in this regard.


Yep I agree. But updating the podspec is changing only the s.version entry in the podspec (personally I set the s.source { :git => … :tag => s.version.to_s } so that the git tag to use is inferred from the version) whereas changing the version in the header means going thru every public header of MR, not just one place, so this is much more work and more prone to errors ;)


@AliSoftware I've no intention of adding the version to every header. A couple of specific, easily-determined places will do. I'm also talking about adding a method that users of the framework can call that will log or return the version of MagicalRecord — this will be useful to people working with a pre-compiled version of the library in their projects.

Your points are true, but don't really solve the original problem that @wm-j-ray reported.


Ok, got it :+1: What about a script to ease your work then, than will automatically:

  • Change the version in those specific headers (using some sed magic for example to change the value of some #define for you)
  • Commit it and tag your master with the version number as the tag name
  • Generate a copy of the latest MagicalRecord.podspec file and upgrade the s.version of this new podspec (sed too here?), ready to be commited and pushed onto CocoaPods

This will ease your work and avoid potential omissions by doing all at once :wink:

Magical Panda Software member

Uh, why do we need this for EVERYFILE? Why not have an API like [MagicalRecord version] return a structured version number (struct { major, minor, hotfix })...isn't that enough?

Magical Panda Software member

@tonyarnold how should CocoaPods work with this changes? Should the podspec creates the BuildConfig.h file?


Good point — I'm intending to check-in an updated version of this file with each release, but I'm still ironing out the issues. Reopening until I do.

@tonyarnold tonyarnold reopened this

can you checkin this file please


@JanC — it has been fixed in develop for a couple of days. The BuildConfig.h file was replaced as part of f5a1edc.


Righto, I've changed this so it's more maintainable. You can either check the double MagicalRecordVersionNumber or + [MagicalRecord version] — the valid values are listed in MagicalRecord.h.

@tonyarnold tonyarnold closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.