Arch is the upstream for manjaro, so you can report there for packages coming directly from arch. For the customized packages there is no such thing as “outdated” since manjaro is the “upstream” for itself so the packages are always “up-to-date”.
I have however the feeling you are not entirely acquainted with the concept of branches in manjaro, so here is some more reading Switching Branches - Manjaro
$ mbn info freecad -q
Branch : archlinux
Name : freecad
Version : 1.1.1-2
Repository : extra
Build Date : Sat 18 Apr 2026 06:24:30
Packager : George Rawlinson <grawlinson@archlinux.org>
Branch : unstable
Name : freecad
Version : 1.1.1-2
Repository : extra
Build Date : Sat 18 Apr 2026 06:24:30
Packager : George Rawlinson <grawlinson@archlinux.org>
Branch : testing
Name : freecad
Version : 1.1.1-2
Repository : extra
Build Date : Sat 18 Apr 2026 06:24:30
Packager : George Rawlinson <grawlinson@archlinux.org>
Branch : stable
Name : freecad
Version : 1.0.2-8
Repository : extra
Build Date : Wed 17 Dec 2025 00:13:01
Packager : Caleb Maclennan <alerque@archlinux.org>
The above is a pretty bad advice. Why would anyone want a git version from aur which is older than the version in the repos? I would not even comment on the chaotic aur… the user is on stable and does not even know manjaro has branches, please do not advise him to break his system.
By the way Freecad has even got an appimage on their site, in case the user does not want to change branch.
Don’t use chaotic-aur if you’re on Manjaro Stable. Its content is automatically compiled for Arch, which corresponds to Manjaro Unstable.
Also, you really don’t want to blindly accept a blanket signature for that whole repository, given that the AUR has already featured malicious content in the past, and whatever makes it into the AUR also by definition makes into chaotic-aur, because it’s an automated build system.
The first question would be if it is only about this single application? Because one can’t expect in general that an application is available in a distribution almost as soon as it is released by its developers. In such a case one would rather check if the application is provided cross-distribution - for instance regarding FreeCAD the developers provide also a Flatpak.
But maybe as others already said this is sort of a repetition of the “Keepass held back in testing” thread.
A git versions age in AUR is not important - as the name implies it build directly from the developers git repo.
A lot of things is possible
custom packages from AUR
AUR helpers (yay,paru,pamac…)
third-party repositories
Because an option is available - that does not mean it is a good option - and one should be aware of the pitfalls.
custom build scripts - should be vetted carefully
AUR helpers - should be used with caution (only apply after vetting the script)
third-party repositories - unless it is your own - you don’t know if the content is safe
As for the alternative formats - anyone can publish those - so use caution, be a little suspicious and a little paranoid - you will fend of most dangers that way
If you count a publisher/vendors latest stable release - then you are correct.
Q: Is there a Manjaro Repository website like the arch one? A: No, there is not.
Watch the Announcements > Testing Updates thread to get an idea of when the next stable snap occurs - usually - when testing snaps are piling up with a few days between - it can be read as sign of an upcoming stable snap - and if you look at the Announcements > Stable Updates thread you will get an approximate indicator of when the next stable snap is going to be.
The option to flag a package as outdated makes sense on Arch Linux because they compile packages from source.
I makes no sense on Manjaro because Manjaro repos are synced from Arch repos.
Outdated on Manjaro is a relative term as packages may exist in different versions throughout the branch structure.
If you want a quick view of a give package’s state in Manjaro repo, sync the package manjaro-check-repos. This gives you the mbn utility - which you can use as GUI or from CLI as you prefer.
And the package is up-to-date at the Manjaro Linux extra repo for unstable and testing branch.
But as - already mentioned several times - the main feature of Manjaro is the stable branch - a branch which provides a reasonably stable Linux experience without constantly applying updates..
How you want to use Manjaro is entirely up to you.
If you want to use stable branch - then you just have to wait until the next stable snap.
If you want to change the update frequency - then you switch branch
The first appearance of version 1.1.* is on Mar 29, 2026. This would mean the package “was lagging behind” on Arch for almost 8 months too, which is wrong. Because comparing with Releases · FreeCAD/FreeCAD · GitHub minus all the development builds and pre-releases that don’t count shows there isn’t anything lagging behind. @linux-aarhus explained in detail how rolling works for Manjaro on the different branches.
So at the end of the day it was about switching branches as i thought. I allowed myself to click this as a solution (one can of course use the official appimage or the aur) because the user seems to prefer the packages as soon as possible and this is manjaro unstable. Which is actually arch stable.
I often check Branch compare for Manjaro to compare package versions across the 3 Manjaro branches. It is very easy to use and provides a simple but clear way to see this info.
“Rolling” does not imply “bleeding edge”. Manjaro is rolling because of how the system is updated, i.e. through bundled updates, rather than by wiping out your installation and installing from a new ISO.
Manjaro is a curated rolling-release system, and curation takes time. If you want to be on the very latest, switch to Manjaro Unstable, or go with Arch proper — which is as bleeding-edge as it gets, and then in case you want to report a package as out-of-date or broken, you’d be right at the source of the packages we provide in Manjaro, because they are our upstream.