You'd have to raise the version yourself, however DeltaBaseYearDayOfYear doesn't work that way, it would be something like:

Dec 31st 2010: "1.35365.0.0"
Jan 1st 2011: "1.36001.0.0"

Where 35/36 is the difference between the build year (2010/2011) and the project start date, which is configurable, but defaults to 1975 IIRC.

AFAIK, there is no versioning scheme that would cause what you say, none of them ever resets to 0, but I could be wrong, never used all of the styles.

EDIT: Well, the TimeStamp style could be a lower value, although I don't see why anyone would use it alone as a minor or build version number, I think it makes more sense to use it with some of the other styles.

Hi Neverbirth,
thanks for the reply.

I think there's a bit of a bug with the Interface generation in FlashDevelop and the automatic code creation template in your plugin.

I'm using this as my template:

which generates this as code (BuildVersion.as):


Occasionally, though I create a new interface by going Right-click -> Add -> New Interface. I'd create an interface something like this:


When use the interface in a class and go to run the game I'll get 2 errors:


I open BuildVersion.as and the code is now:


(BuildVersion becomes ITest and the package changes to the package I added the interface in)

This will continue to do this until I close FlashDevelop and restart it. I'm using FD 3.2.2 RTM and the AutoVersion featured in AutoVersion 1.2.10174.2053.rar at the google code page.

Have you come across this before?

Yes, I'm aware of it, a coworker came across it once, and I've seen it once as well, however, since I couldn't manage to reproduce it as often as I'd like I left the issue aside... I know where the problem comes from, but it's part of the FlashDevelop core code, and didn't find a solution that felt completely right, maybe I'm using a wrong method to replace those template variables, and there is a better one inside the FD API.

I'll look into it again, but I don't know when I'm going to have some more spare time to spend on this.

I cannot believe it's been more than 5 months since the last update...

At last had the time (mostly because my team was suffering from it) to update the plugin:

- Added the fixed AS 2 template that was uploaded back in July 8th.
- Fixed a bug causing the plugin not to work correctly in some cases if spaces are used for indenting.
- Fixed the problem that was causing FD to sometimes change $(FileNameWithPackage) and $(Package) with latest class or interface added to the project.
- Compiled against latest released PluginCore and ProjectManager just in case.

You can get AutoVersion 1.2.11047.1757 here.

ver.1.2.11047.1757 have some problem.

my autoversion plugin is at bottom of all plugins.
and it is avoid. If I click to select it.
it alert a board:
"Setting
Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately.

The type initializer for 'AutoVersion.GlobalIncrementSettings' threw an exception."

I use fd 3.3.4 rtm

Released a new version to fix a long standing bug that caused the plugin to throw an exception if it was disabled.

http://code.google.com/p/autoversion/do ... 1.2112.fdz

it running excellent!!

I got a simple custom autoversion templete for as3.
https://docs.google.com/leaf?id=0ByCQf0 ... ZTU0&hl=en

Hi.
Quite a nice job and everything seems to work fine except just two things.
When working with AIR project the <version> tag in application.xml is appended each time rather then just content of it being replaced.
So the file ends up looking like this:

Also it prints <version xmlns=""> where this xmlns attribute makes the file incompatible with AIR Application Properties.

Thanks for the report. I guess both problems were introduced by the changes made to target .Net 2.0.

This week will release a new version with the problem solved and a version for FD4.

I'm moving house, and aside from the time it takes, the telecom company has left me without phone and internet for 15-20 because of an error on their side, so sadly, the update will have to wait a bit...

Released a new version fixing the AIR versioning problem, and targetting FD 4.

Sorry for the delay, but moving took longer than expected, I had to repair several faults caused by my daughter in the old house before returning the keys to the owner if I wanted my deposit back heh.

Lord I can't believe I have only just found this plugin!?

Is there a way in which i can customise how the numbers are calculated based on which configuration I used to build the project? For example we have maj.minor.build.revision, can i get 'build' to increment when building in Debug configuration and 'minor' to increment when building in Release configuration?

Also, I have noticed that the increment takes place even when I call the .jsfl file to build my project. What is the plugin linked to as its 'trigger' so to speak? Is there anyway I can get your plugin to do its thing with a command line call? The reason being is I think I can coax it into including SVN revision information. I would need to:

1. Call your plugin on command line, to output a .txt file.
2. Call tortoiseSVN's SubWCRev with that file as the template.
3. Call the build script to build the project based on the output file.

Is this possible in the current guise? Could it be a feature added if not? I think regardless of how developers use your plugin, being able to customise when the increment happens during the build process would be beneficial.

There is also lamenace's plugin.



The versioning is triggered when FlashDevelop itself issues the events ProjectManager.ProjectManagerEvents.TestProject and ProjectManager.ProjectManagerEvents.BuildProject, or ProjectManager.ProjectManagerEvents.BuildComplete if you are using the increment after build option.



Have you looked into the Happy Turtle plugin? It's on AutoVersion site. It already supports using SVN revision number for versioning projects.



Developers can make their own plugins for AutoVersion, just create a project, reference the AutoVersion assembly, and subclass the BaseIncrementor class. However, what you propose isn't or cannot be done because of the following things:

• The incrementors don't know if you are in debug or release mode. I think your idea is nice, there are several ways of accomplishing it, the one I like more (because it would give more power to custom incrementors) would be to add a BuildAction CurrentBuildAction property to BaseIncrementor, however, it could break the codebase compatibility with BVI; the other "good" way of doing this would be modifying the VersioningStyle class, adding four new properties (BuildActionType MajorUpdateMode, BuildActionType MinorUpdateMode, etc) and check for those properties inside VersioningStyle.Increment.
  The first method has also the downside that it would require one to make custom incrementors for just some trivial feature like this, although both changes could be added, of course.
  
• In order to correctly work, the plugin takes data from the FlashDevelop environment, so it makes launching the plugin from the commandline a bit hard. A separate console application could be made, and inject from it the needed data for the AutoVersion library, but I don't know right now the efforts it would need. FD offers some data like external paths, some coding formatting set up in settings, author name, etc.
  I don't think this is something I'd add, at least in some long time. If Adobe would add a command line compiler for Flash Professional projects so they could be easily compiled from a CI server this would definitely be a feature of my interest, but not right now, sorry.

Thanks, will see if I can bend that plugin to my will also.



I have, and unfortunately I need a little more control than just adding the revision number of the project. Ideally I need to be able to get the revision details for the main project, but also for each svn:external associated with it too. Hence my need for customising the build and needing to call SubWCRev.



Ahh sad bunny. Looks like I am going to have to go back to the drawing board for my build then. Will have to involve a script somewhere down the line me thinks. We have something that kind of works in Python right now, but what I was hoping for was to be able to replicate it with a combination of some kind of plugin, some JSFL and BAT files.

This is off topic but in case you have an idea that might spark something off in my head. This is my dream of what I want to happen:

Build in Debug:
[*]Hit build.
[*]Increment build number.
[*]Gather information from repos, including externals. (I can make a template file that works with both your plugin and SubWCRev.)
[*]Convert the last two steps into a .as file that is linked to the build.
[*]Build the project.

Build in Release:
[*]Hit build.
[*]Gather information from repos, including externals.
[*]Exit if there are mixed or uncommitted revisions. (Figured this out already.)
[*]Increment minor revision number, reset build number.
[*]Build the project. (This is a check.)
[*]Exit if there were compile errors. (Fail-safe.)
[*]Commit version number info to repo, and update. (Currently done in Python script.)
[*]Gather information from repos again, to ensure all up to date.
[*]Convert version info, along with repo info to .as file that is linked to the build.
[*]Build the project.