There are major changes from Phoenix 1.2 to 1.3 and I want to give it a try. So, is it possible to install Phoenix 1.3 ?
@alexandrubagu I assume you googled the getting started page and it suggests you to install those versions. I think this is major issue with Phoenix documentation that it does not label clearly what is current and what not and people land on Phoenix docs from Google and try to install very old versions, I saw this before.
This is very old version of phoenix you try to install. Current version is 1.2.1. And you can always fetch the most up to date version with:
mix archive.install https://github.com/phoenixframework/archives/raw/master/phoenix_new.ez
Ref. Phoenix guides. Go to main Phoenix web site page, and click link to access guides for most recent version. Google’s results often reference old versions, as noted above.
I watched ElixirConf and there are major changes from Phoenix 1.2 to 1.3 and I thought I can install the 1.3 version. Sorry, my mistake, I’ve edited the post
You can install 1.3 now, wohoo!
I have tried googling for instructions on how to revert from 1.3 to 1.2.1 (on Ubuntu), but can’t find any. I have experienced a slow down in compile times (on a 1.2.1 project) since moving to 1.3, and want to check if this is down to the new Phoenix version or something else on my system. Any pointers much appreciated.
deps, roll back your CVS, done.
If you want to try 1.2.1 on your current codebase, simply try to change your mix-file to that version. If your app isn’t working then, the effort to make it 1.2 compliant is roughly the same as rolling back your CVS and reimplementing the features you have added since then…
Thanks for your help, Nobbz. I think my code is fine, it just takes forever for changes to compile. I think the trouble I am having is down to
- Having a working version of iNotify so that the app actually rebuilds on source change. (I probably installed this at the same time as 1Phoenix 1.3)
- Possible sub-optimal configuration such that when I make a change to an HTML file (Elm) the whole application seems to rebuild - at least it takes a long time for the app/js file to appear.
- Traffic jam affect when saving changes to several source files in quick succession (view/update/model etc.).
- Running Ubunutu under a VM with only 2GB RAM
Thanks again for getting back to me.
I had similar issues running under Ubuntu on a VM. inotify was the culprit but couldn’t solve the issue.
I give up on VMs for phoenix and just stick to macOS now and everything is fine.
After a long slog I have slashed compile time from over six minutes to well under one, which is workable. This ‘phenomenon’ is particular to scenarios where a 3rd party compiler (in my case elm-brunch) generates a js file, which is then processed by Babel with the intention of wrapping it up into a singe app.js file along with other goodies, such as socket.js. The elm js file is half a megabyte, but is generated by elm-brunch pretty quickly. Babel, however, sets about including it into app.js as though in a Parisian restaurant wanting to savour every morsel of code and follow each one up with a swig of burgundy; it takes an age. My solution was to exclude the elm directory from the remit of Babel, and to compile the elm files straight to priv/static/js and include that file separately in the HTML page.