@qft Thanks for adding -cf suffix to the url.
I just wanted to note that provides=("pycharm-eap") is not needed at all. From the wiki page https://wiki.archlinux.org/title/PKGBUILD#provides

Do not add pkgname to the provides array, as it is done automatically.

It may make some sense to add provides=("pycharm") instead, but even that is not needed (as of now at least), because no package require a "pycharm" as a dependency.

So I suggest just removing this provides=("pycharm-eap") from PKGBUILD.

I support @ericatkin comment. Additionally, even provides=("pycharm-eap") is not needed.

@qft Can you please edit source urls similar to how it is done in the pycharm package? I.e. adding "-cf" suffux after "https://download":

if [[ $_eap = false ]]; then
    source=("https://download-cf.jetbrains.com/python/pycharm-professional-${_pkgver}.tar.gz"
    "${pkgname}.desktop")
else
    source=("https://download-cf.jetbrains.com/python/pycharm-professional-${_buildver}.tar.gz"
    "${pkgname}.desktop")
fi

Can we add the following to allow EAP and regular to be installed side by side?

diff --git a/PKGBUILD b/PKGBUILD
index 5b6721b..b0f8518 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -25,7 +25,7 @@ optdepends=('ipython: For enhanced interactive Python shell inside Pycharm'
             'python-pytest: For support testing inside Pycharm with Python'
             'python-tox: Python environments for testing tool with Python'
             'jupyter-notebook: For support Jupyter Notebook')
-provides=("pycharm" "pycharm-professional")
+provides=("pycharm-eap")

 if [[ $_eap = false ]]; then
     source=("https://download.jetbrains.com/python/pycharm-professional-${_pkgver}.tar.gz"

@qft I suggest removing "pycharm-professional" from "provides", because there is no more separation between professional and community editions.

@navarroaxel No, it makes lots of sense. See previous comments.
TLDR is that it allows the compare algorithm of pacman to never fail (considering the jetbrains scheme of naming downloaded archives), and also very understandable by human.

If in the version "251.23774.444_2025.1-1" you are complaining about "_2025.1" part, this is opionated, but I think this still is useful.

Hi! the version of this package doesn't make any sense. check webstorm-eap (e.g. 251.23774.424-1) or rustrover-eap (e.g. 2025.1pre+251.23774.316-1) as useful alternatives. Thanks!.

Hey @qft / @Ashark!

To handle versioning changes correctly, you’ll want to increase the epoch by one. Here's how you can do it:

epoch=1

Setting the epoch to 1 ensures that version checks prioritize the new scheme. This way, even if the older version number (e.g., 2024.3.243.18137.19-1) looks "larger" than the newer one (243.22562.180_2024.3.1-1), updates will still work as expected.

Why is this important? Well, without the epoch bump, users who already installed the package before the versioning scheme change wouldn’t get updates automatically. This happens because 2024 is interpreted as "greater" than 243. By adding an epoch, you force the update and avoid any confusion.

Oh, wow. The current version is 243.22562.23, while their currently released version is 243.21565.199. How is that possible?

I guess, it appeared in https://www.jetbrains.com/updates/updates.xml, and then they closed EAP program, and then updates.xml stopped listing that 243.22562.23 build.

I am thinking how correct it is to then list the 243.22562.23 as a current eap (as it is delisted).