Testing dev versions

[thetechnobear]

a quick thought and tip for other devs out there about testing the master branch version of axoloti.

To ensure I test the development version properly prior to release, I like to use a full packaged version rather than running it from the 'build directory' .

The main reason for this Axoloti runs in a 'special developer' mode whilst running in the build directory, which could mean differences from the released build. (we try to minimise this, but for some things its inevitable to ensure an easier dev cycle)

ok, so to help this in 1.0.10, I introduced 'versioned homes', this resolves the issue that Axoloti always goes to look for your prefs file etc in ~/Documents (or windows equivalent, so you can't run multiple versions.
I explained this in 1.0.10 releases notes here

Running multiple versions of Axoloti
Axoloti now supports 'versioned home directories', this means you can run different versions of Axoloti, side by side.
by default, axoloti will look for its home directory in ~/Documents/axoloti ( and the windows equivalent)
BUT if you have a version specific home directory it will use that instead, for 1.0.10 the version directory would be called:
~/Documents/axoloti_1_0_10 (again, similar on windows)

Ive found this useful for testing out new releases, whilst having the 'stable' one around for use.

Notes:

On the Mac, when I install Axoloti I simply rename the application e.g. call it Axoloti-1.0.10
On windows, the installer will automatically overwrite the old axoloti app, so the approach on windows is to rename the 'old' version before you install the new version.
currently the runtime is compatible with new and old versions so no extra steps are required, but this can be set in preferences if they diverged (unlikely!)
the version directory, is derived from the version compiled into the app (as noted in the about box etc), it is unrelated to the application name, which you can call what you like.

ok, so this is useful for testing and support...

BUT there is a slight issue in dev, currently we don't tag the build with a new version until its released (this may change in the future) ... so the way I got around this was to tag my own local repo with a new version, do an ant clean (to ensure version.java is recreated) and then used this dummy version.

but I didn't like having this extra dummy tag, but Ive realised today this is unnecessary , instead we can just force ant to use a specific version number, so we build with

ant -Dshort.version=1.0.99 -Dbuild.bundle=true

this forces the version to 1.0.99, whats nice about this is you still keep the same long version... so its actually identifiable as a dev build.

so from here, I do as before , install this new built version , renaming it to Axoloti_1_0_99 (so it doesn't overwrite my other Axoloti in my Applications directory), duplicate my existing 1.0.10 home directory, and rename it to ~/Documents/Axoloti_1_0_99
then when I run this axoloti, it will warn me its a versioned home, and will rename things that are necessary

NOW... an extra step, of course there is no axolti-factory or axoloti-contrib at 1.0.99... so we need to run against a particular branch, for now, as its compatible it can be 1.0.10... but might be master if dev has diverged.
so we do this by preferences and then edit the libraries, and change the revision (do not add contributors details!!

NOTE: you will need to enable expert mode to do this!

thats it, sync libraries and your done...
running a packaged version of Axoloti dev, using the 1.0.10 libraries, and alongside your proper 1.0.10 release.

a couple of parting notes:

• updating the bundle with a new dev build , you must remember to use -Dshort.version=1.0.99 on your ant build... but of course when its installed, you'll already have your 1.0.99 axoloti home, so that doesn't need to be redone.
• do not put your contributor details into the community library section. this is because they would be deemed potentially incompatible with 1.0.10 - so if you do, 1.0.10 will refuse to load them, saying they are from a future version of axoloti.
  of course this does NOT stop you developing objects/testing the editor etc. just save them locally in 1.0.99 and then when done copy to 1.0.10 home, edit them, and change the app version to 1.0.10. then start Axoloti 1.0.10 and they will load, and gives you an ideal time to TEST them in 1.0.10, if they work ok, then you can sync your libraries as normal.
  this process means we don't get incompatible dev versions in the library.
  note: if I find/or have reports of 'dev versions' in the community library, I will remove them without question, assuming its done accidentally