ETA for 3.0.0

29 views
Skip to first unread message

konrad....@netcentric.biz

unread,
Jan 7, 2021, 1:24:44 PM1/7/21
to AEM Core Components Developer Community
Hi,
In the slide 10 from the adaptTo's talk "Core Components Status Update" (https://adapt.to/2020/en/schedule/core-components-status-update.html) a release 3.0.0 was mentioned which was about to be released end of 2020. This date was obviously missed. Is there already a new ETA for that release? 
Maybe also https://github.com/adobe/aem-core-wcm-components/wiki could be updated with features supposed to be included in 3.0.0.

Currently all issues targeted for 3.0.0 (https://github.com/adobe/aem-core-wcm-components/issues?q=is%3Aissue+milestone%3A3.0.0) are still in "Open" state and the last commit to branch 3.0.0 (https://github.com/adobe/aem-core-wcm-components/tree/3.0.0) happened last May and only 6 commits are not in the current "develop" branch (https://github.com/adobe/aem-core-wcm-components/compare/development...3.0.0)

The only actual new feature in that branch seems to be https://github.com/adobe/aem-core-wcm-components/issues/713.

Am I missing something here?
Thanks for any input,
Konrad


Vlad Băilescu

unread,
Jan 14, 2021, 2:59:15 AM1/14/21
to AEM Core Components Developer Community
Hi Konrad,

We've been postponing a major release for a while now. Indeed, the biggest change will be the link handling. Since that would require creating new versions for a few of our components, our product management figured we should take the time then to make all backwards incompatible changes in that release. Unfortunately, that changes list kept growing and it's becoming harder and harder to schedule time to address them all.

Personally, I'm pushing for breaking this into smaller changes:
1. Release 3.0.0. with improved linked handling
2. Tackle incompatible changes on a component-by-component basis and create new versions in minor 3.x.y releases.

That might lead to components getting two versions bump over the next few months, which is not ideal, so not everyone is sold on this.

We'd love to hear the community's opinion on this.

Thanks,
Vlad

--
You received this message because you are subscribed to the Google Groups "AEM Core Components Developer Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aem-core-componen...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aem-core-components-dev/c488e66b-20a8-4b7d-a9de-9abfb920178an%40googlegroups.com.

Konrad Windszus

unread,
Jan 14, 2021, 3:14:54 AM1/14/21
to aem-core-co...@googlegroups.com
Hi Vlad,
thanks for the answer.
I do agree that gathering multiple breaking changes in a 3.0.0 release will be too hard as the number of changes will be too big to manage.

So I am very much in favour of releasing 3.0.0 with only improved link handling (some outstanding concerns are not yet addressed though: https://github.com/adobe/aem-core-wcm-components/issues/713#issuecomment-599634086)
Afterwards you can introduce other breaking changes per component in minor 3.x releases.

It would be good to announce already a plan on how many component versions are gonna be maintained in the future in paralel (I guess only two). Also it would be important to know for coonsumers how long the deprecation phase will last at least (before a version will finally be removed).
Also there needs to be a list of components being deprecated published in the wiki. In addition there should be the properties cq:deprecated and cq:deprecatedReason maintained on the component definition for deprecated components (that way one can automatically check already during build time with tools like https://github.com/Netcentric/aem-classification/tree/master/aem-classification-validator.

One other option would be to support deploying multiple versions of Core Components at the same time, but that probably requires some more code changes, as e.g. OSGi services will be deployed multiple times then (like https://github.com/adobe/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/services/CaConfigReferenceProvider.java). Most probably for singleton OSGi services you will have to add a service.ranking = version to make sure that always the newest version is being taken.

Cheers,
Konrad

Stefan Seifert

unread,
Jan 14, 2021, 5:49:12 PM1/14/21
to aem-core-co...@googlegroups.com

i’m also for making smaller steps and getting 3.0.0 released soon.

 

the problem with the current 3.0.0 branch is that is completely outdated and cannot be updated by git merging – as following the decision on this list (https://groups.google.com/g/aem-core-components-dev/c/ITKYKRjqRBI) i had to *copy* lot of existing code for the affected components as base for a 3.0.0 version. and this code is now completely outdated as the components have improved much on the existing versions. i assume it is now easier to drop the 3.0.0 branch and start from scratch again. this is another reason why it’s not good to keep a branch for a major version open longer than a few weeks, because once you start copying code of a component for a newer version, you have to apply every PR on the existing version of the component also to the copy to keep it in sync – a tedious and error-prone process, and not part of the incoming PRs as they target only the development branch.

 

i would be happy to take care of outstanding issues around the new link handling, but i think i have currently not the time to re-recreate the whole 3.0.0 branch with copying everything again (https://github.com/adobe/aem-core-wcm-components/pull/862).

 

stefan

 

Reply all
Reply to author
Forward
0 new messages