⏫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.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:

# in mix.exs

# remove this:
{:recode, "~> 0.6", only: [:dev, :test]},

# and replace it with this:
{:styler, "~> 0.11", only: [:dev, :test], runtime: false},

# in .formatter.exs

# replace:
plugins: [Phoenix.LiveView.HTMLFormatter, Recode.FormatterPlugin]

# with:
plugins: [Phoenix.LiveView.HTMLFormatter, Styler]

Then, replace the content of .credo.exs with the one in this repo.

Finally, run the formatter for Styler to take care of things:

mix deps.get && mix format

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`.

{:petal_framework, "~> x.x.x", repo: :petal}

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.

# clone petal_pro
git checkout -b petal_pro --track origin/main
git checkout main

# develop your codebase
touch lib/new_file
git add -A
git commit -m "Added a new file!"

# petal_pro updates
git checkout petal_pro
git pull
git checkout main
git rebase petal_pro

Option 4 - Attempt a git merge

git remote add petal_pro [e-mail]:petalframework/petal_pro.git
git fetch petal_pro
git merge petal_pro/main --allow-unrelated-histories

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.