Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
AutoVersioning Plugin
JGM:
--- Quote from: MortenMacFly on June 27, 2007, 11:30:36 pm ---Ouch! :shock: That's obviously not as it should be... I need to have a look at this.
--- End quote ---
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)
JGM:
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
thomas:
--- Quote ---And what type of plugin this should be to work correctly? cbToolPlugin?
--- End quote ---
That's what is the most intuitive thing.
--- Quote ---Major Version: increments by 1 when the Minor versions
--- End quote ---
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.
dmoore:
--- Quote from: thomas on June 28, 2007, 11:47:52 am ---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.
--- End quote ---
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.
tiwag:
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"
*/
--- End quote ---
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: ---autobuildnumber version.h "#define APPVERSION"
--- End code ---
hth, regards, tiwag
[attachment deleted by admin]
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version