Author Topic: AutoVersioning Plugin  (Read 134056 times)

Offline JGM

  • Lives here!
  • ****
  • Posts: 518
  • Got to practice :)
AutoVersioning Plugin
« on: June 27, 2007, 08:18:25 pm »
Here the Auto Versioning plugin 1.0

[Changes 1.0]
  - Now the plugin uses the project file to store settings instead of the ini file, thanks to killerbot.
  - You can choose where to store the version.h header as change the filename.
  - You can choose where to store the changeslog as change the filename.
  - The settings tab option AutoIncrement has been changed to Do Autoincrement, because of some different behaviour.
  - Also the Commit Changes menu was renamed to Increment Version.
  - Now the version.h file is parsed to obtain the version values.
  - You will have to increment version before closing the project if changes, since it doesn't store the modified flag as a configuration anymore.
  - The build history is now part of the header file.
  - Many other internal changes thanks to killerbot.

[Changes 0.9.1]
  - Small change, now variables are declared const to suppress warnings

[Changes 0.9]
  - Added a scheme validator to support the user while entering the values (error when dividing by zero on Revision random maximumn).
  - Changed some strings from Auto Versioning to Autoversioning
  - Now the project menus are disabled when no project is active.
  - Edited some menu comments and make them shorter.

[Wiki] (actually I have to update the wiki since the plugin has changed a little)
Check the new wiki page for documentation of the plugin and updated screenshots:
http://wiki.codeblocks.org/index.php?title=AutoVersioning

[Downloads]

Win32 Binary compiled with rev. 4711:
http://prdownload.berlios.de/autoversioning/autoversioning-v1.0.win32.7z

Ubuntu 7.04 Binary compiled with rev. 4711:
http://prdownload.berlios.de/autoversioning/autoversioning-v1.0.ubuntu.7z

[Sources]

Svn: svn://svn.berlios.de/autoversioning (most recent sources)
« Last Edit: December 09, 2007, 03:50:59 am by JGM »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9504
Re: AutoVersioning Plugin
« Reply #1 on: June 27, 2007, 09:02:26 pm »
I see that the plugin classes only implement a few events. Like attach and release, but I don't see events like onmenuclick or something like that.
Have a look at cbEVT_COMPILER_STARTED -> that's what you need to listen to.

And what type of plugin this should be to work correctly? cbToolPlugin?
That's a good choice I'd say.

With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline JGM

  • Lives here!
  • ****
  • Posts: 518
  • Got to practice :)
Re: AutoVersioning Plugin
« Reply #2 on: June 27, 2007, 09:22:14 pm »
Have a look at cbEVT_COMPILER_STARTED -> that's what you need to listen to.

Thanks for your reply, I will try that.
« Last Edit: June 29, 2007, 10:43:39 pm by jgm »

Offline JGM

  • Lives here!
  • ****
  • Posts: 518
  • Got to practice :)
Re: AutoVersioning Plugin
« Reply #3 on: June 27, 2007, 10:30:25 pm »
The compiler plugin is not generating EVT_COMPILER_STARTED or notifying the other plugins about this event. But is generating an EVT_COMPILER_FINISHED so i decided to increment the file after the compilation is finished. And thinking it now is the correct way of doing it. (Now increments before compilation using a wxTimer). Well, now it use the cbEVT_COMPILER_STARTED to make the changes necessary.

But how I know if the project was successfully compiled? Not so necessary now by the commit changes feature.

Edit:
cbEVT_COMPILER_STARTED still doesn't work. now work! fixed on revision 4324.
« Last Edit: August 25, 2007, 03:15:21 am by JGM »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9504
Re: AutoVersioning Plugin
« Reply #4 on: June 27, 2007, 11:30:36 pm »
The compiler plugin is not generating EVT_COMPILER_STARTED or notifying the other plugins about this event.
Ouch! :shock: That's obviously not as it should be... I need to have a look at this.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline JGM

  • Lives here!
  • ****
  • Posts: 518
  • Got to practice :)
Re: AutoVersioning Plugin
« Reply #5 on: June 28, 2007, 02:33:54 am »
Ouch! :shock: That's obviously not as it should be... I need to have a look at this.

I imagine that, I make some OnCompilerStarted and OnCompilerFinished function events, but only the OnCompilerFinished was being notified. I expect to finish this plug in tomorrow if I understand right the api, but it seems very clear, I'm just impatience. :roll:

I got a question, with what configurations the wxWidgets dll was compiled?
I compiled codeblocks with my own compilation of wxWidgets and in result the plug in is not calling the correct libraries with the nightly version. The plug in works great with my codeblocks compilation. In linux there should not be any problem, because the official wx libraries are used instead, and no custom libraries. I will try on ubuntu too.  8)

Offline JGM

  • Lives here!
  • ****
  • Posts: 518
  • Got to practice :)
Re: AutoVersioning Plugin
« Reply #6 on: June 28, 2007, 04:46:28 am »
I was searching for version formats and I'm not sure what format I should implement. For example I was thinking on this:

Major Version: increments by 1 when the Minor versions sums 10
Minor Version: "      " by 1 when the Build Number sums 100 (reset on 10 to 0)
Build Number: every time the program is compiled successfully increments by 1
Revision Number: increments by one when some file has changed

This is a link with some tips:
http://www.codinghorror.com/blog/archives/000793.html

I was also thinking to add some defines that indicate the date of the build: year, month and date. And define each Version number on separate defines, integers or strings like: major, minor, build, revision. So the user has the flexibility of output the version in the format he wants. Also generate this defines:

#define RC_FILEVERSION  1,0,0,0
#define RC_FILEVERSION_STRING  "1, 0, 0, 0\0"

for windows resource files...

Any suggestions are welcome :D

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: AutoVersioning Plugin
« Reply #7 on: June 28, 2007, 11:47:52 am »
Quote
And what type of plugin this should be to work correctly? cbToolPlugin?
That's what is the most intuitive thing.

Quote
Major Version: increments by 1 when the Minor versions
That's not what I would do. I would never change major numbers or minor numbers in an automatic way, since that's not what people normally expect.

Personally, I would not even increment build numbers automatically, but instead would use a number provided by the revision control system for that. Compiling the same source ten times should not increment the build count by 10, there is no change to the code, so this doesn't justify changing the number. On the other hand, if the revision number has changed, then obviously code has been modified, and the build number should be amended.

There are many different schemes and many more interpretations. Most commonly, the major.minor.release scheme is understood as:
  • major: big change in functionality, may have entirely different look and feel, and may even not be backwards-compatible (although that's usually a requirement nevertheless)
  • minor: must not break compatibility, no matter what, may contain major or minor improvements, but no gross changes in overall look and feel
  • release: bug fixes or insignificant changes

However, in some circles, it is also understood as:
  • major: must be a bigger number than the competitor's product
  • minor: increments with every new feature
  • release: increments by a random amount in regular intervals, even in absence of changes to code

An interesting approach to versions (which we similarly plan to use in Code::Blocks, too) is the year.month scheme as first made famous by Ubuntu. A release coming out in April 2007 would be named 7.04. The big advantage is that it requires no maintenance at all, and it is still unique and looks cool. Also, comparing  6.08 to 7.04 provides a lot better information than than comparing "Netscape 4" to "Netscape 7", for example.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: AutoVersioning Plugin
« Reply #8 on: June 28, 2007, 01:02:18 pm »
An interesting approach to versions (which we similarly plan to use in Code::Blocks, too) is the year.month scheme as first made famous by Ubuntu.

I hope this is the case. releasing this C::B as v1.0 RC3 would be a mockery of version schemas and bad marketing to boot.

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: AutoVersioning Plugin
« Reply #9 on: June 28, 2007, 02:54:43 pm »
i'm using an autobuildnumber tool,
which increments only the last number

from the docs

Quote
/**
@file
@author Ryan Mulder
@author Steve Pierce
@date 3/13/06
Usage:
   The first command line argument is the path to the file to edit  (typically a resource file or header).
   If only the first argument is supplied, the "FILEVERSION" field is incremented
   If additional arguments are supplied, they are the string to search for before the version number. Example:  "#define AutoBuildNumber"

    Valid version numbers are a list of numbers separated by any one of:
        ,.|\\/&*^%$#@+-_=`~?<>:
    However, only 1 of these separators can be used at once.
   Version numbers can be contained inside double quotes or not, and only the last value will be incremented by this app.

   Example: #define AutoBuildNumber 1.0.0.1
   Example: #define AutoBuildNumber "1,0,0,1"
*/

and use it with CodeBlocks by defining a pre-build step
in "Project -> Build Options -> Pre/post build steps"
 
eg. if my version info is in file version.h  and  the macro name is APPVERSION
the you need a pre-build step like
Code: [Select]
autobuildnumber version.h "#define APPVERSION"
hth, regards, tiwag

[attachment deleted by admin]

Offline JGM

  • Lives here!
  • ****
  • Posts: 518
  • Got to practice :)
Re: AutoVersioning Plugin
« Reply #10 on: June 28, 2007, 03:00:03 pm »
Personally, I would not even increment build numbers automatically, but instead would use a number provided by the revision control system for that.

Well so I will give the user the option to not increment this values automatically and if the user wants to increment the values automatically use a default scheme.

On the other hand, if the revision number has changed, then obviously code has been modified, and the build number should be amended.

You mean with "amended" that the build number should be incremented when the revision number is incremented? Sorry not a native english speaker  :roll: So with what you said above increment the revision by random numbers from 1 to 10 and the build number by one.

major.minor.release scheme is understood as:
  • major: big change in functionality, may have entirely different look and feel, and may even not be backwards-compatible (although that's usually a requirement nevertheless)
  • minor: must not break compatibility, no matter what, may contain major or minor improvements, but no gross changes in overall look and feel
  • release: bug fixes or insignificant changes

Substitute the build number and revision by the release?

year.month scheme as first made famous by Ubuntu.

Right, I thought this. I want to declare some defines with the date month and year and maybe one define that declares some UBUNTU_STYLE_VERSION with the y.mm. The only problem for know is that no EVT_COMPILER_STARTED is been fired, and is needed to update the file before the compilation takes effect.

Well i will start working on this right now :D

Offline rjmyst3

  • Multiple posting newcomer
  • *
  • Posts: 117
    • wxFormBuilder
Re: AutoVersioning Plugin
« Reply #11 on: June 28, 2007, 06:53:12 pm »
i'm using an autobuildnumber tool,
which increments only the last number

from the docs

Quote
/**
@file
@author Ryan Mulder
@author Steve Pierce
@date 3/13/06
Usage:
   The first command line argument is the path to the file to edit  (typically a resource file or header).
   If only the first argument is supplied, the "FILEVERSION" field is incremented
   If additional arguments are supplied, they are the string to search for before the version number. Example:  "#define AutoBuildNumber"

    Valid version numbers are a list of numbers separated by any one of:
        ,.|\\/&*^%$#@+-_=`~?<>:
    However, only 1 of these separators can be used at once.
   Version numbers can be contained inside double quotes or not, and only the last value will be incremented by this app.

   Example: #define AutoBuildNumber 1.0.0.1
   Example: #define AutoBuildNumber "1,0,0,1"
*/

and use it with CodeBlocks by defining a pre-build step
in "Project -> Build Options -> Pre/post build steps"
 
eg. if my version info is in file version.h  and  the macro name is APPVERSION
the you need a pre-build step like
Code: [Select]
autobuildnumber version.h "#define APPVERSION"
hth, regards, tiwag

This tool is open source and uses wxWidgets.

It looks like it does a very similar thing to what the plugin will do, so if the source will help you get started you can find it on google code.
http://code.google.com/p/autobuildnumber/

You can checkout the source from its svn repository here:
http://autobuildnumber.googlecode.com/svn/trunk/

Offline JGM

  • Lives here!
  • ****
  • Posts: 518
  • Got to practice :)
Re: AutoVersioning Plugin
« Reply #12 on: June 28, 2007, 07:15:17 pm »
This tool is open source and uses wxWidgets.

It looks like it does a very similar thing to what the plugin will do, so if the source will help you get started you can find it on google code.
http://code.google.com/p/autobuildnumber/

You can checkout the source from its svn repository here:
http://autobuildnumber.googlecode.com/svn/trunk/

Thanks, I have already downloaded the zip file that attached Tiwag  :)

Offline JGM

  • Lives here!
  • ****
  • Posts: 518
  • Got to practice :)
Re: AutoVersioning Plugin
« Reply #13 on: June 28, 2007, 10:48:49 pm »
So far this is what is been output by the AutoVersioning when configured with a project.

Code: [Select]
//version.h file

//Date Version Types
#define DATE_VERSION 28
#define MONTH_VERSION 06
#define YEAR_VERSION 2007
#define UBUNTU_VERSION_STYLE 7.06

//Standard Version Types
#define MAJOR_VERSION 1
#define MINOR_VERSION 0
#define BUILD_NUMBER 0
#define REVISION 0

//Miscellaneous Version Types
#define BUILDS_COUNT 1
#define RC_FILEVERSION 1,0,0,0
#define RC_FILEVERSION_STRING "1, 0, 0, 0\0"
#define FULLVERSION_STRING "1.0.0.0"

Now I will implement the AutoUpdate Functions :)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5187
Re: AutoVersioning Plugin
« Reply #14 on: June 28, 2007, 11:13:55 pm »
suggestions :
 - don't use defines (bad, preprocessor and ancient C shit)
 - use static const int or something like that
 - put them in a special namespace to avoid collisions