with 2.3.0 generated.c is changed too often


#1

generated.c is updated by developer studio very often, it will added/updated a timestamp to adl_InitApplicationVersion.
this is odd if you use a version control.

const ascii adl_InitApplicationVersion[] = “1.1.9.20121212173737”;

thanks,

Luca


#2

See the thread, “Developer Studio 2.3.0 - Released

https://forum.sierrawireless.com/t/developer-studio-2-3-0-released/5995/1

There certainly needs to be a way to disable that feature for those that do not want it :exclamation:


#3

The goal of this feature is to make sure you can identify a given build of your application at any time, and it has been enabled by default to let you not worry about it.
Indeed, sometimes the version is not enough: a build identifier helps to… well… identify a given build for a same “version” :wink:
That’s pretty useful when you start playing with continuous integration, etc…

Anyway, please note that:

  • we’ve paid attention to not break incremental build: generated.c is updated only if another project file has been updated, or if a library project that the app is depending on is modified.
  • and if you prefer, the build identifier can be removed in the Developer Studio > Build preference page.

#4

let do the source code versioning to versioning tools (cvs, svn, git…) :slight_smile:

it changes if you modify the Readme file in your project, even if the sources or the project configuration is untouched.

If you need the build timestamp, an alternative could be:
TRACE (( WD_TRACE_LEVEL, DATE ));
TRACE (( WD_TRACE_LEVEL, TIME ));
or
#define myProductVersion “1.2.3 (” DATE " " TIME “)”

Anyway it can be disabled therefore is not an issue!
Thanks,
Luca


#5

As daav said, it is common to have both a “version” id (from the version-control tools) and a “build” identifier.


#6

Dear all,

Interesting to read your feedback related to this feature. As David mention, target is to identify build number of your application. Let me give you a bit more insight related to this:
Some customers are regularly proceeding to over the air application update (feature update, issue correction), and with AirVantage Management Services, they were having difficulties to distinguish the Open AT application version between 2 version.
Especially due to the fact that most of the time the application version was forgotten to be updated (the one in generated.c).
Customer are then facing discrepancy while they are managing a whole fleet of device where all application version answer are the same but the behavior is different.

Target is to help preventing this situation to our customer while they are remotely managing application update.