Hello Tim Thanks for your time to give me a detailed explanation which will help us with our update / migration decisions.
I understand that updating the frameworks for all three currently supported versions can be difficult and requires a lot of effort. However, in my opinion, the statement in your wiki regarding security updates is a bit misleading, if it does not also apply to keeping main dependencies up-to-date, and this should at least be mentioned somewhere. Best regards Mathias DSpace Developers schrieb am Dienstag, 30. September 2025 um 19:11:03 UTC+2: > Hi Mathias, > > While we do our best to upgrade dependencies in prior releases, Angular > upgrades are often quite complex. So, we've had to take the policy of > (often) keeping each DSpace major version *pinned* to a major version of > Angular. This means that if you want to upgrade Angular, it's best to > upgrade your entire DSpace release. > > The reason for this decision is that Angular upgrades usually are not > straightforward, and often require touching very large numbers of files. > For example: > * Here was our DSpace upgrade to Angular 16: > https://github.com/DSpace/dspace-angular/pull/2871 > * Here was our DSpace upgrade to Angular 17: > https://github.com/DSpace/dspace-angular/pull/2934 > * Here was our DSpace upgrade to Angular 18: > https://github.com/DSpace/dspace-angular/pull/3717 (this also required > an upgrade to Bootstrap 5: > https://github.com/DSpace/dspace-angular/pull/3506) > > Each of these PR is very large (2K-8K range), touching a very large number > of files. Additionally, some Angular upgrades require other upgrades (like > Angular 18 requiring also upgrading to Bootstrap 5), which makes the effort > even larger. > > Because of the size of these Angular upgrades, when institutions perform > these, they often will need to perform manual updates to their themes and > similar. This makes the process much more similar to a *major upgrade* of > DSpace, instead of a minor upgrade. This is why we recommend the approach > of upgrading your entire DSpace rather than attempting to "patch" a DSpace > 7 or 8 site up to Angular 18 / Bootstrap 5. In many cases it'd be *easier* > for sites to upgrade to DSpace 9 than to backport these patches to an older > version of DSpace. > > Additionally, as you noticed, because our DSpace major release schedule > doesn't always match up well with Angular's major versions, there are > sometimes gaps where an Angular release might go out of free support before > our next DSpace major release. But, in that scenario, it's worth noting it > is possible to purchase Angular commercial support for sites that need it. > See https://endoflife.date/angular and > https://www.herodevs.com/support/nes-angular. > > All of the above is not to imply we'd *never* backport an Angular major > version upgrade. If the Angular major version is mostly "backwards > compatible" and provides a more seamless upgrade process, then we'd gladly > include it in a minor DSpace release. It's just been our experience that > this is not often the case. > > Everything above is much more specific to the frontend. With regards to > the backend, we do our best to upgrade Spring (and similar backend > technologies) in minor releases *where possible to do so*. In some > cases, the upgrade is minor and can be done easily. But, in other cases, > it's not possible because the extent of the upgrade is too complex. For > instance, DSpace 7 still uses Spring 5 and *cannot be easily upgraded to > Spring 6. *The reason is that Spring 6 *requires* using Jakarta EE, which > was a massive change requiring upgrades also to Hibernate, Flyway, etc. > See https://github.com/DSpace/DSpace/pull/9321 > > This again was such a large change that backporting it to DSpace 7 would > prove highly complex. Instead, sites should upgrade to DSpace 8 or 9, which > both use the latest versions of Spring 6 and Spring Boot 3. > > Overall, our approach is to do our best to backport security fixes for > transitive dependencies *within reason*. If they are easy to backport, > we'll do them immediately. But, in the situation of Angular (and sometimes > Spring), some are highly complex to backport, as they require updating > other major dependencies as well. So, in those scenarios, we > unfortunately have to "pin" that DSpace major release to specific major > releases of Angular (and sometimes Spring), and tell users to upgrade their > DSpace if they want these dependencies updated. > > I hope this helps clarify the situation, but further questions are welcome. > > Tim > On Tuesday, September 30, 2025 at 11:22:22 AM UTC-5 [email protected] > wrote: > >> Hi there >> >> According to >> https://wiki.lyrasis.org/display/DSPACE/DSpace+Software+Support+Policy >> >> > The DSpace Committers provide security updates/support for the *most >> recent three (3) major releases >> <https://wiki.lyrasis.org/display/DSPACE/Releases#Releases-ReleaseNumberingScheme> >> *of >> the platform. >> >> As i can see, the version 7 branch of dspace-angular uses v15 for >> Angular, version 8 branch uses v17 and version 9 branch uses v18. >> >> The only active supported Angular version of these three is v18, which is >> supported until this november (!). >> >> This leads to transient dependency vulnerabilities. >> In our project we have multiple moderate to critical security alerts >> which are related to the outdated Angular version used. >> >> The same questions arise with regard to the backend. At least without >> paid enterprise support for the Spring framework. >> >> IMHO updating to newer / maintained Framework versions should be part of >> the actively maintained DSpace versions. >> >> Is there any ongoing discussion in this matter? >> Would you accept PRs increasing the Framework version? >> >> Best regards >> Mathias >> >> -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/dspace-devel/8c232472-f862-4d85-a641-fa8c0802953cn%40googlegroups.com.
