View unanswered posts | View active topics



Reply to topic  [ 83 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next
AutoVersion 
Author Message
Moderator

Joined: Mon Jul 06, 2009 8:14 am
Posts: 258
Reply with quote
Well, my first FD plugin and created-by-me open source project. Inspired by the version plugin made by lamenace and by the Build Version Increment addin for Visual Studio, I've decided to make my own plugin.

By now it's an initial release that took me just a few hours to make, and a lot of the code is based on the VS addin, not because of a lack of ideas or because of laziness, but because of its extensibility, this way people could reuse plugins made by others or use them with just minor modifications. The problem is the base class used for it lives inside the addin assembly, so the plugin model used won't correctly work, I'm going to contact the people behind it to see if they could extract the base class, or study if I should add a reference to their assembly.

There are a couple of features that don't work yet, but will fix it as soon as I have some spare time. I also have a feature in mind that am going to add soon.

You can download the first version, and the source code here:

http://code.google.com/p/autoversion/

I wanted to add the Version menu item to the Project menu, but after checking how it is added, decided to abandon that initial idea, and add it to the Tools menu.

Any comment, question, or suggestion, is welcome.


Last edited by Neverbirth on Wed Apr 28, 2010 7:47 am, edited 1 time in total.



Thu Apr 22, 2010 11:19 am
Profile
Member

Joined: Wed Mar 03, 2010 1:44 pm
Posts: 72
Location: LYON, FRANCE
Reply with quote
nice but why making new one ?


Thu Apr 22, 2010 9:35 pm
Profile
Moderator

Joined: Mon Jul 06, 2009 8:14 am
Posts: 258
Reply with quote
Released a new version with support to set the build start date used on some of the versioning styles, the path and name of the version file, and its package.

EDIT: File updated, since there was a silly bug with the build start date. Also, updated the code so the version file was encoded using the configured default codepage.

lamenace wrote:
nice but why making new one ?


Well, why not? IMHO, there is nothing wrong with it. Both plugins supply different features.

My team uses a different versioning method than the one your plugin provides, and some of the inner workings of the plugin and the reply I got when asked for different versioning schemes somewhat took me away from it (no offence intended at all), so decided to give it a try on my own.


Sat Apr 24, 2010 5:48 pm
Profile
Moderator

Joined: Mon Jul 06, 2009 8:14 am
Posts: 258
Reply with quote
New version uploaded.

- Use of FileHelper where applicable.
- Correctly set the version class name.
- Added the possibility to use templates for the version file.

The template feature lets you use whatever file format you want, for example you could use:

Code:
package $(Package) $(CSLB){
   
   /**
   $(CBI)* ...
   $(CBI)* @author $(DefaultUser)
   $(CBI)*/
   public class $(FileName) $(CSLB){
      
      public static const VERSION:String = "$(Major).$(Minor).$(Build).$(Revision)";
      
   }
   
}


And get this as a result:

Code:
package Data
{
   
   /**
    * ...
    * @author
    */
   public class Versiondata2
   {
      
      public static const VERSION:String = "1.0.10116.40";
      
   }
   
}


Since the plugin doesn't support other languages than AS3 (yet), you can also use this feature to support MXML files, haXe projects, etc.

Also, forgot to mention, that although the plugin doesn't natively support version numbers based on SVN revisions, thanks to it being based on the Build Version Increment add-in, anyone should be able to easily use Happy Turtle Plugins or other plugins written for this purpose.

I haven't tried this myself, but since BaseIncrementor is placed inside the main assembly I guess the only step needed should be to recompile the plugin, referencing AutoVersion instead of BuildVersionIncrement.dll, and changing the corresponding namespaces. I'm in conversations in order to avoid this process.

However, it may not work even so, since there is a parameter being passed to plugins that I'm missing. It's rather easy to implement tho, but haven't done so since I've wanted to concentrate on other things first. Would be interesting to know which results people get.

EDIT: Updated the uploaded file. There was a hardcoded string thay could cause problems with the template feature, and also AutoVersion now passes the missing argument to other plugins based on BVI.


Mon Apr 26, 2010 9:30 am
Profile
Member

Joined: Thu Feb 09, 2006 10:58 am
Posts: 1095
Location: Israel
Reply with quote
I've added it to the plugins list. :)

_________________
MovieClipCommander


Mon Apr 26, 2010 6:02 pm
Profile
Moderator

Joined: Mon Jul 06, 2009 8:14 am
Posts: 258
Reply with quote
IAP wrote:
I've added it to the plugins list. :)


Great, thank you!


Mon Apr 26, 2010 6:07 pm
Profile
Member

Joined: Sat Nov 15, 2008 4:00 am
Posts: 171
Reply with quote
Conflict with this plugin viewtopic.php?f=4&t=4641&hilit=exportproject

Icons of ExportProject plugin are meny meny meny .... meny times duplicates on toolbar :D


Tue Apr 27, 2010 11:46 pm
Profile
Moderator

Joined: Mon Jul 06, 2009 8:14 am
Posts: 258
Reply with quote
Strange, I do nothing fancy when initializing the plugin, do not send or dispatch other events, nor modify the toolbar.

Will look into it, may be some minor thing.


Wed Apr 28, 2010 7:24 am
Profile
Moderator

Joined: Mon Jul 06, 2009 8:14 am
Posts: 258
Reply with quote
Found it.

Somehow ExportProject doesn't like that I add the Version menu item as the first item in the Tools menu.

Will contact the author to see what he thinks.

You can fix it in the meantime by replacing these lines in PluginMain.cs:

Code:
                toolsMenu.DropDownItems.Insert(0, _versionMenuItem);
                toolsMenu.DropDownItems.Insert(1, new ToolStripSeparator());


With:

Code:
                toolsMenu.DropDownItems.Add(new ToolStripSeparator());
                toolsMenu.DropDownItems.Add(_versionMenuItem);


Although this will make the menu item to appear at the bottom of the Tools menu.


Wed Apr 28, 2010 7:38 am
Profile
Moderator

Joined: Mon Jul 06, 2009 8:14 am
Posts: 258
Reply with quote
Released a new version:

- Added an option to choose between incrementing version before building or after the build is finished. Like in BVI. Note: The build complete event isn't dispatched on Flash IDE projects.
- Version dialog size slightly increased.
- Start Date value was being saved with a wrong name. Fixed.

The ExportProject problem is still present, I'm waiting for the author to check for it.


Wed Apr 28, 2010 10:24 am
Profile
Moderator

Joined: Mon Jul 06, 2009 8:14 am
Posts: 258
Reply with quote
Made a quick FAQ on the Google Code site:

http://code.google.com/p/autoversion/wiki/FAQ

Hope it will be helpful to everybody. If someone has other questions or things to add, post here. Thank you.


Wed Apr 28, 2010 12:03 pm
Profile
Member

Joined: Thu Sep 08, 2005 8:32 pm
Posts: 301
Location: Virginia
Reply with quote
Looks promising! I definitely like the "variable" approach so I don't have to rely on a single version file.

One feature I love from the other "Version" is the ability to query SVN, and I wonder if that could be another variable.

_________________
Image Open source makes me open my wallet for an open world of goods.


Wed Apr 28, 2010 3:18 pm
Profile YIM WWW
Moderator

Joined: Mon Jul 06, 2009 8:14 am
Posts: 258
Reply with quote
tangent wrote:
One feature I love from the other "Version" is the ability to query SVN, and I wonder if that could be another variable.


That's covered at the bottom of this post, and in the FAQ I've added just today.

I couldn't test it myself yet, and it would be nice of somebody else could give it a try and post the results he got, since I prefer to work on improve some features or add some new ones I have in mind before checking it, but if nobody does by the end of this week, I'll try to get some spare time for it myself.

Today I've also added a roadmap to the Wiki page of the project, and noticed two variables weren't being initialized correctly when there was no previous settings file availble, I'm not uploading any new binary just for that tho, will do it once I add my next feature in the list.


Wed Apr 28, 2010 3:31 pm
Profile
Member

Joined: Wed Aug 01, 2007 3:37 pm
Posts: 1223
Location: Grizzly Flats, CA
Reply with quote
I haven't tried this plugin, but I'm guessing you're putting an item under Tools > Flash Tools? Is that correct? Or are you putting it under Tools, and that's causing ExportProject to place it somewhere other than Tools > Flash Tools?

Ultimately this will be affected by which plugin is initialized first, which may be different depending on the user. I think there's a strong reference (id) available for the Tools menu, but I'm not sure that there's one available for Tools > Flash Tools. I'm probably using an index value because I want to make sure that it will still work even if the titles are localized ... searching for a title value would be less reliable than using an index.

Perhaps you could place your menu items under one of the existing trees, like "Flash Tools", "Web Tools" or "General Tools", or perhaps you could create your own, new menu item, rather than putting it under tools, or perhaps you could place it in the tools menu, but underneath the "Flash Tools", "Web Tools" and "General Tools" items?


Wed Apr 28, 2010 6:22 pm
Profile WWW
Member

Joined: Wed Aug 01, 2007 3:37 pm
Posts: 1223
Location: Grizzly Flats, CA
Reply with quote
I'm also a little curious how this plugin works. Does this version only when you create a file, or does it work each time you compile? Can you place the template text in any file in the project, or does it need to be a class file? Can you have multiple projects in the same directory, without them overwriting each other?

One thing I would LOVE to be able to do, though probably out of the scope of the plugin's current features, is to update an XML file with the build number or build date of each supporting file.

Caching is a pain when loading child assets. Different browsers are terrible about caching files which have actually been updated. As a result, I have a "lastUpdated" value which I keep in an XML file. The solution that many take is to throw a random number at the end of their child URLs, but I think this is very inefficient. That requires the client to download the child files every time they visit the site, which is particularly awful if they are trying to pull it up from their cache while browsing offline.

As a result, I append my "lastUpdated" value instead, which means that it breaks the cache when I updat this value, but otherwise allows the client to keep their cached version. It would be really awesome to be able to update this automatically, so that when I compile each project, it updates it's version value in the XML file, but I'm not entirely sure how that would work from a development standpoint.

Thought I'd just throw it out :)

EDIT:

It wouldn't have to be an XML file, actually, and it wouldn't have to contain any data other than the compile times. For example:

Code:
<projects><project name="MyProject" build="1.00.10" /><project name="MyOtherProject" build="2.1.20" /></projects>


Wed Apr 28, 2010 6:29 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 83 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.