Note from the maintainer of this project.

[tetranz]

Hi all

It's me, the maintainer of this project.

I hate to say this but despite my brief burst of enthusiasm about two and a half years ago that didn't amount to much, I really need to be honest and say that I no longer have the bandwidth or motivation to maintain this project. The reality of life and the fact that it's not relevant to my work these days means that I need to face this fact and not mislead anyone. I'm not setup validate the latest PRs.

I thank everyone for their continuing efforts. I feel bad every time I see a new PR.

So ... what to do? I guess there are only two options that I can take to help things continue in some way.

I haven't been following forks but if there is clear winner among forks or even a small number, I'm happy to link to them prominently in the readme.

If someone really wants to volunteer to take over as maintainer then I guess I can add them as a collaborator. I don't know how I would realistically vet anyone but if you want to volunteer then please send me an email to tetranz at gmail.com. I'll give preference to someone who has already contributed here or at least can point to other open source projects they've worked on.

Thanks again and I'm sorry it's come to this but I guess it's not an uncommon situation in the open source world.

[Chris53897]

@tetranz Thanks for all your work.

I did some modernization in the php part. But this fork will handle primary our company needs.
The goal is to keep it working for us with the latest php and symfony version.
https://github.com/Chris53897/select2entity-bundle/tree/feature/php-8.0 (After testing i will merge it to the master of the fork)
The important changes in the scope of symfony for the near future are in #184

Without Tests it is hard to maintain and i see that there are some complex issues.
I hope that someone with more JavaScript knowledge can do some modernization in that part.

Shortlink for status of Forks https://github.com/tetranz/select2entity-bundle/network

[RomainOdeval]

@tetranz yes, thank for all your great work.

I think it will be great to find someone (and maybe "someoneS") to be collaborator.

They are currently 9 PR, all are important, good and not so big.
Maybe @Chris53897 and another person (i can but you never saw me, on this project, of course) can check those, create a new version (3.2.0 ?) and think about future more calmly after that ?
I thin those PR resolved a lot of issues.

[tetranz]

Oops, I posted first as the wrong user. :)

Thanks all. I'm okay merging a PR if at least one person (although more than one would be better) other than the author verifies it.

If I tag a release and something bad happens then we can always revert or users can simply ignore that release. Hopefully most people have their composer settings locked to a tag.

[Chris53897]

Sounds good. But i am not sure how much i can help testing with the other PRs.

What php version is the desired one?

= 7.4? >= 8.0 ?

Before you tag it we can have Tester that check if everything is correct. Installable bei "dev-master". You can make a branch from the actual "master" as backup.

Another solution is to make a branch (maybe "dev") from the actual master and rebase PRs to this. But some PR are older, so maybe author of PR is not involved anymore and maybe we need to create a new PR. But this should be only take some minutes to recreate the PRs.

[RomainOdeval]

@Chris53897 i think it will be great for users to do like that :

1. Test and merge PRs about fixes and "options added" but keep 7.2 compatibility
2. Add a changelog file using "Keep a Changelog format" then create a v3.2.0
3. Merge PR about PHP7.4 and create a v3.3.0 only for this
4. Merge PR about PHP8.0 and create a v4.0.0 only for this
5. Then, check all other issues (clean resolved ones) and do what we can to improve/fix the others

[Chris53897]

@RomainOdeval

I understand your way, but this is adding more work for maintainers with fixes and PR by PHP-Version (branch).
I agree with creating a changelog file.

The actual php version constraint is ">=7.1.3".
The problem i like to solve is with Symfony 6. This needs php > 8.0.2 anyway.

1. I prefer to go to php > 8.0.2 directly and fix PRs that i understand.
2. Release a new major version.

There is no other critical PR (in my eyes) that we need to maintain in more branches.
Composer is handling the dependency, so there is no BC break.

PHP 7.4 will reach EOL in november 2022. This would be a reason to support it.
But to lower the burdon of maintainers i suggest to got to php 8 directly.

WDYT?

[RomainOdeval]

@Chris53897 Yes, i understand and you are right.
The only thing that remains in my head is that a lot of production servers have not be updated to PHP8 because they wait PHP 8.2 to appear (because you can't have break changers after x.2 versions).
To be fair, i work for an IT company and i will not said to my customers to go to PHP8 now because of that.
So, for some annoying bugs like "text_property", they will wait at least one year to have a fix. Quite sad.

I suggest to create at least a minor version with PHP7.4 compatibility and most annoying bugs fixed (only PR already created, of course !) then create a new major version.
If you want, i can work on those PR (rebase, etc ...) to help but i think it will be quick : if we don't count "PHP8 compatibility" PR, we have only 8 PR and they are not so big.