[Meta] Automate the new release process

[LeaVerou]

There is currently a sequence of steps for a new release, described in https://github.com/mavoweb/mavo/blob/master/CONTRIBUTING.md#steps-for-new-release

This should probably be automated, with a script that accepts the new version as a command line argument and takes care of everything that needs to be done locally. That could either be a bash script, or a node script, or something like that.

[DmitrySharabin]

I would also suggest removing pointers to the source maps (since we don't provide them) from the final files before moving them to the separate folder corresponding to the new release. It will calm down browsers when authors use a stable or any not dev version of Mavo. We can add a new task (e.g., build) to the gulp file that extends the default task by adding a new step that does exactly that.

[LeaVerou]

What do you mean we don't provide them? We should!!

[DmitrySharabin]

I have a question then. Just to make sure I understand everything correctly.

Before releasing a new version, we copy all the files (mavo.js, mavo.css, etc.) to the corresponding folder. E.g., to the 0.3.0 folder. To make source maps work, we must also copy the maps folder to the 0.3.0 folder (and fix source files paths). Even though we don't do that now, we can do it starting from the next release by tuning a bit the build process. Not a problem at all. :) So, we must get the folder structure, like this one:

dist
  |
  |
  - 0.3.0
      |
        - mavo.js
        - mavo.css
        - ...
        - maps
           |
              - mavo.js.map
              - mavo.css.map
              - ...

After releasing a new version, we continue working on Mavo, and the source files we have in the src and scr-css folders don't correspond to the source maps we have for the previously released Mavo version. It seems to me that the old source maps are beneficial only if one downloads the release assets (source code) from GitHub, not when includes a specific version of Mavo (that is served from our CDN) into their app. Do you think we should also copy all the source files to the corresponding folder (e.g., 0.3.0) inside the dist folder? What do I miss?

[LeaVerou]

Oh I see, you're absolutely right. Yes, relative source maps don't make any sense in that case. I see two ways forward:

1. Either we just remove the source mapping annotations, to avoid 404s.
2. Or we convert them to absolute URLs, pointing to the files using that version of Mavo.

I'm tending to go with 1, which is far easier, since I'm not sure there are that many use cases where the source maps would be useful for these released versions (if we need to debug locally, we'd do git checkout v0.2.x and go from there, right?)

[DmitrySharabin]

I'm tending to go with 1

I’m leaning towards this option too. So, we have two votes. :)

if we need to debug locally, we'd do git checkout v0.2.x and go from there, right?

Absolutely. Now we have everything we need to make it work.

[karger]

I may be an outlier, but when I run into a bug I try to debug in place; i'm to lazy to check out sources.

On 10/31/2021 11:02 AM, Lea Verou wrote:

Oh I see, you're absolutely right. Yes, relative source maps don't make any sense in that case. I see two ways forward:

1. Either we just remove the source mapping annotations, to avoid 404s.
2. Or we convert them to /absolute/ URLs, pointing to the files using that version of Mavo.

I'm tending to go with 1, which is far easier, since I'm not sure there are that many use cases where the source maps would be useful for these released versions (if we need to debug locally, we'd do |git checkout v0.2.x| and go from there, right?)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mavoweb/mavo/issues/699#issuecomment-955716377, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIWSXTUILLEKOO6MGN2OFDUJVLCFANCNFSM4XDCCFJQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[DmitrySharabin]

And you can accomplish it now if you switch from the Mavo version you are using to the dev one. The source maps we provide with the dev version make the debugging a breeze. Even on Codepen, regardless of what version of Mavo files you are using: either minified or es5. All the source files you might need to debug your app will be at your fingertip right in the browser. :)

[LeaVerou]

I may be an outlier, but when I run into a bug I try to debug in place; i'm to lazy to check out sources.

Yeah, but would you debug Mavo itself? That's what this is about, not debugging your own app.