14 replies to this topic

[Dave Guerin]

Hi Tarek,

 

Another feature request from me...

Could STV NSLog it's version number when it's first included, or have a method on SCTableViewModel that returns a version?

 

Maybe it'd also be useful for each STV framework to NSLog their version number as well  (or also have a version method on the main class) just so it was obvious if there was a mismatch between STV framework versions.

 

 

[Tarek]

Hey Dave,

 

We'll need to think of something here, since STV's version number is never hardcoded anywhere in the code itself (all these versions you see in the header files are added by a script only after the framework has been published). We could of course hardcode the version number in a global method, but I am sure this will cause a lot of problems down the road.

[ozie]

can't another script be added that adds a global function somewhere?

[Dave Guerin]

Hi Tarek,

 

Could the version number be a #define for each framework, and your script update that at the same time as the header version?

[Tarek]

Ozie, Dave,

 

A #define could definitely be added via the script, but that means that the framework won't be able to output the version number itself via NSLog for instance, since the value hasn't been actually compiled there. Are you guys ok with just the #define statement?

 

Other solutions could involve scripts adding values/implementations, then compiling the framework afterwards. This is a bit more complex but could still be done if the above doesn't meet your needs.

[ozie]

couldnt STV have a function we can call were the function can read its define and return it?

[Tarek]

couldnt STV have a function we can call were the function can read its define and return it?

 

 

Yeah that's exactly what I was talking about above. If the script changes the #define after the framework has been compiled, it will have absolutely no effect.

[ozie]

maybe im thinking to hard on this, but wouldnt the function just read whatever is in the define and return it.. i must be missing something

 

can't STV have a built in function that reads from its own pList version number and return it?

Edited by ozie, 03 December 2015 - 07:27 PM.

[Dave Guerin]

Hi Tarek,

 

The Crashlytics and Fabric frameworks have a plist file that sits in the root of the framework. In the plist there's a CFBundleShortVersionString key and also a CFBundlePackageType key with value FMWK, among other things.

 

The plist can be altered after the compile, I do that myself to update app CFBundleShortVersionString and CFBundleVersion and a couple of custom keys to show beta status and git status.

 

 

If this is going to hold up the release of the next STV version that I think is imminent then it can wait, it was just something I thought would be useful, not essential.

[Dave Guerin]

Hi Tarek,

 

kSTVCurrentVersion in STV 5.2.0 is working for me, thank you very much.

 

 

A kSTVCoreDataCurrentVersion define in STVCoreData.h would also be great :-) And similarly for the iCloud, Parse and WebServices frameworks to be consistent.....

[Tarek]

Sure, will do.

[Dave Guerin]

Hi Tarek,

 

Thanks very much for kSTVCoreDataCurrentVersion in STV 5.2.1 :-)

[Tarek]

You're most welcome Dave :-)

[ozie]

while we are talking version numbering:)

In my Dash app for the docset it would be nice to know what version it has

at the bottom of the main page it has

"© 2015 Sensible Cocoa. All rights reserved. (Last updated: 2015-12-05)"

 

Is there anyway to add the current version number too? 

[Tarek]

@ozie: We could add a version number, but keep in mind that the documentation version isn't necessarily the same version as STV, since docs are generally only updated when new API is added.