a couple of important notes:
Contributors to the community library
From this release, contributions are uploaded to a specific release.
So, if you upload with 1.0.9, it will not be available in 1.0.10, until I merge it across, which will be done periodically. - I'll do this regularly initially, and then less frequently as we move forward.
My suggestion is contributors therefore move as soon as possible, and this will be a useful way to get your users to move forward to.
as for upgrading, my suggestion is:
- finish any outstanding work on 1.0.9, and then synchronise your library to upload it
- upgrade to 1.0.10, and do sync libraries to move to 1.0.10 (or you can run 1.0.10 alongside to 1.0.9, see below).
note: if you do this, you will NOT see your changes in 1.0.10 immediately.
wait until I merge them... do not start editing the object in 1.0.10, until you see the latest changes are reflected in 1.0.10 when you do sync libs, and do not copy your changes from 1.0.9. if you dom you will cause a merge conflict the next time I do a merge of others 1.0.9 changes, which I will have to resolve manually.
... and then possible later conflicts on your own repo when you next sync, which will cause you grief, you have been warned
the alternative, if you want to see you changes immediately, or carry on working in the object, is to move your changes to one side, upgrade to 1.0.10, then move them back. i.e. make the changes on 1.0.10 and not 1.0.10
a couple of additional notes:
- we will only merge 'forward' i.e. 1.0.9 to 1.0.10 never 1.0.10 to 1.0.9
- please do NOT edit/copy changes between versions yourself, wait for the merge, doing so could possibly cause merge conflicts, which I will have to manually resolve, which in turn could cause additional issues.
- when we make the 'production release' this will have a new version number, and we will do the same process - these test branches will become redundant, and in particular the master branch (used pre 1.0.10) will be 'repurposed' (I'll probably branch it first, to make 1.0.9 branch for posterity.
please also read this post about issues I'm seeing so far
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.
- 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.