You can find a list of new functionalities and fixes for version 4.2.13 and for version v4.4.8.
If you have any improvements you want to contribute back, the best is to use git to get a local copy of the source code from the GeoNetwork GitHub repository, apply the fix and put out a pull request so your improvements can be integrated quickly. Otherwise you can also create new tickets in the GitHub issue tracker.
Thanks and congratulations to all the community members and developers that have been putting effort and energy in these releases and the documentation update.
aside: This vulnerability occurred in the GeoTools which was assigned the CVE-2025-30220 record number, affected software such as GeoNetwork do not get a distinct “common vulnerability and exploit” record. While I have not experienced this personally different national registrars may end up merging reports, I am curious what will happen if anyone wishes to report back on their experience.
After a test upgrade from 4.2.11 to 4.2.13 the logs appear to WARN that a database migration is necessary. Where’s the docs and guidance about how to manage this for GeoNetwork deployments with PG? Some logs say there are sample migrations in WEB-INF/sql/migration but after find they are some in WEB-INF/classes/setup/sql/migrate. Are the migrations manually done or automagic?
Welcome to the user forum @erick-ouellette thanks for joining us here.
GeoNetwork checks the version number of the database on startup, and applies the migrations you found one at a time to make the necessary changes when it is starting up.
GeoNetwork uses an object mapper between the data structures in the application and the database tables. It is generally capable of adding and removing columns as required, but when the meaning of values changes, introducing a new constant, that is when those scripts are used to update the database content.
Thank you. After inspection of the PG tables, it appears the migration to 4.2.13 worked fine. The reason for my upgrade not working is not with the db migration as I superficially thought. There is a software error in the geonetwork log (catalina.out) about an http error in the geonetwork core and the gn portal does not return/render. I raised a ticket in geonetwork-core about it. I hope this is the correct place for this ticket.
It is not a bad place to report, but the development team is small and you may find the user forum more effective to troubleshoot, and then report an error if it can be found (and confirmed to be in geonetwork rather than your setup).
Invalid character found in method name [0x160x030x010x07a0x010x000x07]0x030x030x0bQ0x870xa5[0xd10x170x990x990xce0xc10xfdz0xa9k0xc1=0xee0x0d0xa60xf6t^0xa3{S0xff0xab00xa70xfa0xae ]. HTTP method names must be tokens
That seems pretty odd? A web search shows that this may happen when confusing http and https. Double check your tomcat configuration perhaps?