β«Upgrade guide
How to upgrade your PetalPro project to the latest versions
Version updates can be a bit of a manual process. A boilerplate is meant to be a starting point for you to build from - rather than a framework like Phoenix. However, it is possible.
1.8 -> 2.0
Starting with 2.0, the Petal Framework has returned to Petal Pro. There is a discussion with regards to this change in the PR. The Petal Framework package will be supported in the long run - so there is no need to upgrade immediately. However, over time new features will be added to Petal Pro, rather than the Petal Framework package. If you upgrade to 2.0, you will no longer need to provide your Petal Framework license key. If you have generated a Dockerfile
for deployment, then you can remove the following section:
In addition, the npm
recipe has been merged. Petal Pro is still using esbuild
, however, javascript libraries are now downloaded as an npm package (instead of depending on a CDN).
You may need to add nodejs
and npm
to your Dockerfile
:
In the past mix assets.setup
would install Tailwind CSS and esbuild. Tailwind is now installed with mix setup
, esbuild is installed via npm with mix assets.deploy
. You'll need to remove:
Finally, lib/petal_pro_web/petal_framework_translations.ex
is no longer required. Instead, components like the DataTable
can use Gettext directly.
1.6 -> 1.7
Starting in this release, we now use Styler to format our codebase. This means there will be a large amount of changes. To minimise merge or rebase conflicts when upgrading, we recommend you swap out Recode with Styler first:
Then, replace the content of .credo.exs
with the one in this repo.
Finally, run the formatter for Styler to take care of things:
Another change we recommend you make before upgrading, especially if you've made changes to your landing page, is to rename PetalProWeb.Components.LandingPage
to PetalProWeb.LandingPageComponents
, make sure you also rename the file from landing_page.ex
to landing_page_components.ex
.
Given the amount of changes in this release, we recommend you backup your branch, then use merge
instead of rebase
to bring your branch up to date.
1.5.2
When upgrading to this version, you will need to make your local hex aware of our hex repo. Please follow the instructions here (it involves using a license key unique to you).
Updating Petal Framework
Updating the Petal Framework package is as simple as updating any dependency - simply update the version in `mix.exs`.
Updating the boilerplate code
Here is some discussion amongst members in a Github issue.
Firstly, I'd use {rename_project, "~ 0.1.0"}
to rename your project back to `PetalPro` if you renamed it to something else.
Personally, I'd use option 3.
Option 1 - Copy your files into a fresh project
Manual and time-consuming, but surgical.
If you haven't changed too many existing files and added mostly new ones, you could start a fresh project with the latest Petal Pro and migrate over the work you've done from the previous project. This is likely the easiest route. If you want to keep your git history, then you could try copying the .git
folder from the previous project into the new one.
Option 2 - Using git branches
With this option, you maintain a βpureβ Petal branch in your repository with no other modifications. Then, you merge this branch into your main app when you upgrade.
Follow the instructions here.
Option 3 - Rebasing
Keep a branch in sync with the PetalPro repo, and when it updates, you rebase (replay) your commits on top of it.
Option 4 - Attempt a git merge
Option 5 - rsync
rsync -r --delete --exclude=.git ~/code/petal_pro-1.3.0/ ~/code/your-app
git checkout HEAD path/to/files/rsync/deleted/but/shouldnt/have (I used --delete with rsync so I'd know about files that were removed, for example, I think some of the org stuff was moved, and I don't want cruft)
git add -p
Use rename_phoenix_project.sh to rename back to your app name
Option 6 - Use a diffing tool like Araxis merge
Comment from a Pro user:
The easiest way for me is to create a fresh project from the updated petal_pro, rename it to the same name as your existing project, and then run a diff tool like Araxis merge against the root directories. As long as you have mostly added your own files and not modified the template files much it doesn't take too long. You can either merge the template changes into your existing project (better for git history) or merge your customizations into the fresh project.
Last updated