Hello everyone, You'll find below minutes from our meeting last week, please respond to that email if you have corrections or updates to provide.
Thanks, Francois --- # Participants: - Serge H. - Inoyu - Kevan J. - Jahia - Jonathan S. - Jahia - Francois G. - Jahia - Selim # Meeting minutes ## Migration from Unomi 1x Some challenges were faced when migrating from Unomi 1x to Unomi 2.6x on environments with a large amount of data. In a specific use case, Elasticsearch rollover and automated mapping generation resulted in incorrect mappings being created, causing some future events to be silently rejected. Some mitigation was implemented via this PR: https://github.com/apache/unomi/pull/716, although in the long term, relying on other mechanisms for generating the mapping would be preferable. ## Apache conference proposal Serge mentioned that he submitted talks to the community over code conference, he is currently waiting to hear back and see if these would be accepted. More details are available on this Slack thread by Serge (https://the-asf.slack.com/archives/CBP2Z98Q7/p1741685757786989). ## Unomi 3 A significant section of the meeting was dedicated to discussions regarding upcoming features currently identified as "Unomi 3 features". Currently living in a separate branch, Serge will try to split them in smaller parts to facilitate their review. Serge also mentioned that these features do not have to be breaking and might be portable to the current version of Unomi. Serge has not yet worked on the migration path or studied if/how these changes could be made non-breaking. The main driving factor for grouping these new features under a "Unomi 3" version was to highlight the significance of the changes for Unomi. Francois mentioned that even though a breaking change requires a first-digit bump, the team could also decide, at its convenience, to bump the first digit (i.e. a breaking change would not be required). If the changes around multi-tenancy and authentication can be made non-breaking, having these in the current version of Unomi would likely ease adoption by existing members of the community. The team could then later trigger the release of Unomi 3 (for example make them available in Unomi 2x as "beta" and release Unomi 3 to highlight their readiness for production use). With the multi-tenancy implementation, fields were added to the data model, but the existing Unomi 2x fields were not modified, Jonathan suggested that adding fields should not require a re-indexation of everything during migration and Kevan suggested multi-tenancy be made configurable and maintain the current features working if the fields do not have values. Serge mentioned that he would look into it although he's concerned about the effort required. Regarding the support for OpenSearch some discussions took place regarding the use of parameters to the "unomi:start" command to select the persistence layer (OpenSearch or Elasticsearch), it was mentioned that using a configuration variable might be easier to use. ## Other discussion points Some other discussions took place regarding the migration and potentially using a tool outside of Unomi itself to perform it. This approach might provide some flexibility but at the same time might make it more complex to maintain as it would potentially make it more difficult to follow Unomi versioning. No clear plan was identified and tickets have not been created yet on that front. ## Good first issue A new participant, Selim, joined the call, offered to help, and wondered if there were good first issues. Although we do not have such tickets pre-identified, Serge directed him toward submitting improvements to the documentation. In the future, we might want to look at flagging some issues as "good-first-issue" to help onboard new contributors. # Next meeting Next meeting: Thursday April 10, 2025 - 9AM CET: https://us02web.zoom.us/j/85252119410
