search

mainio / decidim-module-term_customizer

Decidim module that allows customizing the localization terms in the system for specific contexts.
GNU Affero General Public License v3.0
16 stars 21 forks source link

Update to decidim v0.25 #80

Closed andreslucena closed 2 years ago

andreslucena commented 2 years ago

Fixes #79.

As I've mentioned there:

As you know, since version 0.25.0 Decidim uses webpacker for its assets.

@leio10 had already made all the changes for this to work (this was actually in production in Metadecidim for the last couple of months), but I see that he hadn't time to make the PR.

I'm opening this PR just so you're aware of - I'll try to find time next week to make the PR with the cherry-picking myself, but just in case that I couldn't find time or if you prefer to do so yourselves.

https://github.com/AjuntamentdeBarcelona/decidim-module-term_customizer/tree/feature/webpacker-migration

So, all the credit goes to @leio10 ❤️

The only changes that I've made are:

  1. Changing the DECIDIM_VERSION. Originally it was pointing at v0.25.0.dev, and I've left it as v0.25.0, as we already have multiple versions and .dev isn't right anymore.
  2. Adding the Gemfile.lock in the same commit with the spreadsheet gem
ahukkanen commented 2 years ago

Thanks @andreslucena.

The develop branch should already work for v0.25.

In case there is something missing there, could you please rebase this with develop and open the PR against develop instead?

andreslucena commented 2 years ago

The develop branch should already work for v0.25.

Oh, I see, I've been bitten by the GitHub default branch and didn't see the develop branch. Also, I didn't see the version branches for 0.24-stable and 0.25-stable - is there any rationale behind this branches' management that I didn't catch?

Just a couple suggestions for this to be cleaner IMHO:

  1. Change the GH default branch to develop
  2. Create the 0.24-stable and the 0.25-stable branches
  3. Delete the master branch

Or at least document the branches' management in the README, so it's easy to find out

In case there is something missing there, could you please rebase this with develop and open the PR against develop instead?

I started the rebase, but there were lots of conflicts on how the structure of the app/packs directory was done. Just giving it a look with meld, I didn't see anything relevant.

ahukkanen commented 2 years ago

With our modules we GENERALLY do as follows:

This is the general idea but we are just in the process of updating our instances to 0.25 which is why the master branch is still lagging behind (and because 0.26 is not out yet).

andreslucena commented 2 years ago

With our modules we GENERALLY do as follows

Makes sense!

This is the general idea but we are just in the process of updating our instances to 0.25 which is why the master branch is still lagging behind (and because 0.26 is not out yet).

Great! I'm actually in the process of releasing v0.26.0 (it'd be v0.26.0.rc2 as I made a mistake in the release process of .rc1 😅). The thing is that part of the release process is trying the RC out in Metadecidim, that has this as a dependency, I've seen that we were with a fork for this module and I wanted to fix it for once.

So, I'm closing this PR, and I'll open a new one for updating to v0.26 on develop. Thanks @ahukkanen!!