ACS AEM Commons 5.0.0 Release

[davidjgonzalez]

Staging branch: https://github.com/Adobe-Consulting-Services/acs-aem-commons/tree/feature/acs-aem-commons-5.0.0

This issue provides a central location to discuss an ACS Commons 5.0.0, which will drop AEM 6.3 support (therefore a breaking change release)

• What is the advantage in releasing a breaking-change release?

• What would we break in this release

  • [x] Remove AEM 6.3.x support
  • [ ] Do we want to remove any Deprecated APIs? (if so, which and why)
  • [ ] Do we want to remove Deprecated Features? (if so, which and why)
    • Take another stab at #1722 (and getting rid of Felix SCR annotations), we must consider the comments from #1741 though
  • [x] Remove Package Replication UI #2246
  • [x] Moved /var/acs-commons/reports to /conf/acs-commons/reports #2365

• What are the major changes to the project?

  • [x] Upgrade to AEM 6.4.0 Uberjar
    • https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/feature/2288-prepare-release-500/pom.xml#L795
  • [ ] Switch to newest FileVault #2043 to allow to leverage validation feature of packages
  • [ ] Switch to bnd-maven-plugin #1718 (by way of #2423)
  • [x] Principal based service users (for migrated features) and use of [ ] notation in service user mapper (https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/2388)

• MUST haves

  • [x] Upgrade to AEM 6.4.0 Uberjar
  • https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/feature/2288-prepare-release-500/pom.xml#L795
  • [x] Principal based service users (for migrated features) and use of [ ] notation in service user mapper (https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/2388)
  • [ ] Create ui.config project - https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/2456
  • [ ] Create ui.apps.structure project
  • [ ] Re-organize "content" (aka container, our "all") project to embed Bundle Jar (instead of embedding in ui.apps)

• Nice to have

  • [ ] Switch to newest FileVault #2043 to allow to leverage validation feature of packages
  • [ ] Switch to bnd-maven-plugin #1718 (by way of #2423)

• What open issues would this "auto-close"?

  • [ ] #1909
  • [ ] #1975
  • [x] #2029
  • [ ] #1408

[joerghoh]

If we are discussing specifically for the 5.0.0 release, I would only include API breakages (the biggest part coming from the switch to the AEM 6.4 uber jar).

Any change, which can be added on-top of that, should be postponed to a later 5.x version. Otherwise the release is getting too large and risky.

[davidjgonzalez]

@joerghoh I'm talking about BREAKING changes. If we postpone breaking changes, those will be to 6.0.0 release, ideally, we break users as few times as possible.

[kwin]

As #1722 has a slight risk of introducing backwards incompatible changes I would only do it in a major release!

[joerghoh]

@davidjgonzalez we have a few things/topics, which can be considered improvements (e.g. updating plugins like filevault, bnd etc you listed above, but also the ideas @badvision has), but which do have a risk to break APIs or other less formal contracts. I would postpone them to a later 5.x release to keep the 5.0 as large as necessary, but as small as possible.

[joerghoh]

So should we tag the issues/PRPs which will break (or will likely break) backwards-compatibility with a "5.0" milestone? So it's absolutely clear to all, what has to go in? I would then postpone every other PR to a later 5.x milestone.

[davidjgonzalez]

@joerghoh i've made 2 new 5.x.x milestones, that should help us organize issues:

• 5.0.0 is the breaking changes required for 5.x release (and drop of 6.3.x support)
• 5.1.0 is the first non-breaking new feature/technical enhancement release of 5.x.x

Ideally, if we have open bug-fixes, we'd merge and cut a 4.7.2 right before 5.x.x to support anyone that might not be able to undertaking moving to 5.x right away.

Also, @joerghoh, feel free to organize/add/remove/etc. this issue's description w/ what you're thinking for 5.0.0 -- i just roughed it out to get the ball rolling.

https://github.com/Adobe-Consulting-Services/acs-aem-commons/milestones

[joerghoh]

I created a new branch "feature/228-prepare-release-500" [1] here on the ACS repository for the 5.0.0 release, so everyone can start to review, contribute, test, etc.

And once we are all fine, we can merge it master.

[1] https://github.com/Adobe-Consulting-Services/acs-aem-commons/tree/feature/2288-prepare-release-500

[joerghoh]

I merged the current master into https://github.com/Adobe-Consulting-Services/acs-aem-commons/tree/feature/2288-prepare-release-500. the current state is:

• builds against AEM 6.4 uber.jar (build profile: classic)
• builds against AEM CS (build profile: cloudservice)

the only problem is that right the default profile "classic" must be provided explicitly, I was not able to make it really default.

What else do we need to make the 5.0 release?

[kwin]

@joerghoh That branch currently still contains old Felix SCR annotations. We should take another stab at converting them to OSGi annotations (https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/2288#issuecomment-627442894) before releasing 5.0.

Also the OSGi dependencies still state only OSGi R6 support. As AEM 6.4 is not fully AEM R7 compliant, we need to switch to individual OSGi dependencies to reflect the supported versions which is

• DS 1.4
• Meta Type 1.3
• Core fully R7 compliant

I added https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/2422 for that.

[joerghoh]

PRs are welcome :-)

[davidjgonzalez]

@joerghoh we also should do as described in the list in this isssue.

• Switch to newest FileVault #2043 to allow to leverage validation feature of packages
• Switch to bnd-maven-plugin #1718

@kwin IIRC, the switch from Felix SCR to DS 1.4 is the big BC breakage is we cannot have '-' in the OSGi properties names, correct?

[kwin]

the switch from Felix SCR to DS 1.4 is the big BC breakage is we cannot have '-' in the OSGi properties names,

DS 1.4 supports - but Meta Type 1.3 doesn't. Therefore we would have to get rid of all - in property names which are maintainable via Web Console.

@davidjgonzalez Do you still have the feature branch of #1722 at hand? I do no longer see it at https://github.com/davidjgonzalez/acs-aem-commons/tree/feature/1722 unfortunately. That branch would allow to see easily how many properties are affected...

[davidjgonzalez]

@kwin agh - don't think I have that anymore :( .. I periodically clean our old branches and I think this was a victim of that.

@justinedelson did quite a bit of work at the end of that adventure as well - not sure if he has anything useful.

[davidjgonzalez]

@kwin the other question is - do we just wait till we drop 6.4.x support entirely, and use R7 + - support? (6.5.0+ supports this right?) .. keep in mind that removing the - breaks user's code (would be nice to have a find/replace tool if do that) but also need to update docs, screenshots, and any sample packages that might include this.

[kwin]

I thought we reached consensus with https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/1722#issuecomment-458020403. For me that still sounds reasonable. I don't see any strong reason why we should use property names with "." and for that drop support AEM 6.4 as well. From a development perspective meta type 1.4 doesn't provide a lot of new features except for being able to use "." in properties. The rest is more or less on R7 already in AEM 6.4

[kwin]

I merged the current master into https://github.com/Adobe-Consulting-Services/acs-aem-commons/tree/feature/2288-prepare-release-500. the current state is: builds against AEM 6.4 uber.jar (build profile: classic) builds against AEM CS (build profile: cloudservice)

I see that the build still fails at https://travis-ci.org/github/Adobe-Consulting-Services/acs-aem-commons/builds/730570257 because the merge from master was not done correctly. @joerghoh Can you fix this?

[joerghoh]

@kwin : done https://travis-ci.org/github/Adobe-Consulting-Services/acs-aem-commons/builds/734763673 (the failing build seems to be a sporadic error).