Release 3.0.0

[DavidPetrasek]

Try the new version here: https://github.com/DavidPetrasek/ChatBundle

Core functions tested and work fine!

I haven't created a PR, because I believe this package should be renamed to friendsofsymfony/chat-bundle. So I renamed it and if you agree with this change then I propose creating a new Github repository and making this one obsolete/archived and adding a short explanation with a link to the new repository at the begging of the README of the current repository.

What's new (or see the commits in the provided repo)

Codebase upgrade:

• Now supports PHP 8.2 (tested in 8.3) and Symfony 7.2
• Modern Symfony bundle structure
• Migrate XML config to PHP config
• Rename AppBundle to App
• Update access modifiers: change protected to private where applicable
• Replace PHPDocs (@var, @param, @return) with PHP type declarations
• Introduce PHP attributes
• Switch DateTime to DateTimeImmutable

New features:

• Participant's status
• readAt
• deletedAt
• Added optimized version for getFirst(Last)Message methods, specifically getFirst(Last)MessageByThread and getFirst(Last)MessageByThreadQueryBuilder which doesn't load the entire collection
• getNbUnreadMessageByParticipantAndThread
• getNbSentMessageByParticipantAndThread
• getMessageByThreadQueryBuilder
• getThreadsCreatedByParticipantQueryBuilder
• getParticipantThreadsQueryBuilder
• getUnreadMessageByParticipantQueryBuilder
• Sent message is now automatically marked as read for the sender
• getThread method in the Provider class doesn't mark the thread as read anymore
• allow method chaining where missing
• removed method escapeTerm in QueryFactory class which doesn't do anything. It was also a insecure/overhead to escape search strings as we already use/should use prepared statements.
• Mark messages as deleted (for a single participant / for all)
• When a thread/message is marked as deleted, it's not marked as read anymore. There is no way to tell if the participant has really read the thread/message. Even webmail clients like Hotmail and Gmail don't do this.

[lsmith77]

Thank you!

I posted to try and find some other users to double check your work.

https://mastodon.green/@lsmith/114348754691506756 https://bsky.app/profile/lsmith77.bsky.social/post/3lmx3mppx3w2o

[stof]

If this is dropping lots of things without a deprecation-based migration path, maybe it would be better to publish a new bundle from scratch rather than making this a new major version of this FOS bundle. Making a new major version requires a proper migration path (if doing a new bundle, documenting the migration between bundles would still be a good thing, but this migration process might be eased by having an intermediate step with both bundles installed and some provided tooling to help migrate things, which is not possible for a new major version as we cannot install both versions in parallel)

[DavidPetrasek]

@stof Yes, I propose, to set up a new Github repo with a new composer package, with no backward compatibility. I would list the major changes either at the top of README in the old bundle or at the bottom of the new bundle. By "tooling" do you mean to use something like Rector?

[lsmith77]

We can then also add a link to your repo from this bundle to steer people towards your work.

[stof]

Depends on how the migration process looks like. It could be Rector-based, it could be dedicated migration commands or it could be dedicated optional features that makes the migration easier (or nothing at all if not needed).

[DavidPetrasek]

@lsmith77 Since I am not the author It would be best to do either major upgrade of this old version or set up new repo within FOS and after that my temporary repo can be deleted.