How often do we need to update the AEM SDK version in the codebase

@srk_1d It hard to answer as AEMaaCS is new. We should update AEM SDK in case of major feature release from Adobe. It is fine to have as is as this provide backward compatibility. Also, I think it doesn't matter as everything depends on AEMaaCS as it will be having backward compatibility always. In case of any deprecate feature we will be getting a release note from Adobe in one or other way.  

The frequency with which you need to update the Adobe Experience Manager (AEM) SDK version in your codebase depends on several factors:

1. Vendor Release Cycle: Adobe periodically releases updates and new versions of AEM SDK. The frequency of these releases can vary, but major updates might happen annually or semi-annually, while minor updates or patches could be released more frequently.

2. Feature Requirements: If your project requires specific features or improvements introduced in a newer version of the SDK, you might need to update more frequently to take advantage of these capabilities.

3. Security Patches and Bug Fixes: It's crucial to stay updated with security patches and bug fixes provided by Adobe. If vulnerabilities or critical bugs are discovered in your current version, you should update as soon as possible to ensure the security and stability of your application.

4. End of Support: Adobe typically provides support for older versions of AEM SDK for a limited period. It's essential to monitor the support lifecycle and plan your updates accordingly to avoid running unsupported versions.

5. Compatibility: Consider the compatibility of the newer SDK version with your existing codebase, third-party integrations, and any customizations. Updating too frequently might introduce compatibility issues that require additional development effort to resolve.

6. Resource Availability: Updating the SDK version requires resources, including time and effort from your development team. Ensure that you have the necessary resources allocated for the update process.

Based on these factors, you should assess your project's specific needs and constraints to determine the appropriate frequency for updating the AEM SDK version in your codebase. In general, it's recommended to stay relatively up-to-date with SDK versions to benefit from new features, security enhancements, and support. However, the exact frequency of updates may vary from project to project.

Hi @srk_1d 
updating the SDK version in pom.xml won't impact the run time SDK version (run time SDK version will be used from AEM).

The POM version is for development purpose and added with provided scope.

Dependency Scope

Dependency scope is used to limit the transitivity of a dependency and to determine when a dependency is included in a classpath.

There are 6 scopes:

• compile
  This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
• provided
  This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. A dependency with this scope is added to the classpath used for compilation and test, but not the runtime classpath. It is not transitive.
• runtime
  This scope indicates that the dependency is not required for compilation, but is for execution. Maven includes a dependency with this scope in the runtime and test classpaths, but not the compile classpath.
• test
  This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases. This scope is not transitive. Typically this scope is used for test libraries such as JUnit and Mockito. It is also used for non-test libraries such as Apache Commons IO if those libraries are used in unit tests (src/test/java) but not in the model code (src/main/java).
• system
  This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
• import
  This scope is only supported on a dependency of type pom in the <dependencyManagement> section. It indicates the dependency is to be replaced with the effective list of dependencies in the specified POM's <dependencyManagement> section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.

@srk_1d 

We've encountered a couple of situations where the dialogue functionality of an extended AEM component didn't perform as expected following a release.

Adobe consistently rolls out updates, typically on a monthly basis, via pipelines equipped with various checks to ensure smooth upgrades and minimize potential disruptions to instances. An important part of these checks is Experience Audits https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/using-cloud-manager/test-results/experience-audit-dashboard.html?lang=en

While it's impractical to validate the environment after every single release, authors usually uncover residual issues post-pipeline checks. Mostly these are minor ones. If there is anything major, one can request for a rollback of AEM version.

That said, it's advisable to routinely update the SDK version in the pom.xml file, necessitating a local AEM SDK update, which can be time-consuming. Therefore, it's important to plan for these updates regularly, if not on a monthly basis. The frequency of updates should also be determined by factors outlined by @imran__khan 

@srk_1d  Did you find the suggestions from users helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.