[RFC] We should do something

[Padam87]

Hi Everyone,

First of all, I would like to thank @l3pp4rd for his work on this project. He has spent an amazing amount of his free time working on this, and still, to this day he contributes the most to this project.

I think we have reached a point where this project is at a decision point. It would need a major overhaul to make it up to date again.

I propose deprecating the library, and limiting contributions to vital fixes only.

I would like to propose a solution too:

• Create a new organization responsible for this project.
• Use a modular approach, with each extension having its own repository and package.
• Save as much of the current mapping schemas as possible, update code to PHP 7.1+, drop support for older deps.

I think this approach would breathe new life into this project.

• More people would be willing to contribute.
• Extensions could be installed separately.
• Extensions could break BC on their own, allowing a greater pace for development.

We should also cut some extensions entirely. I propose completely dropping Uploadable (in favor of Vich), and adapting KNP's version of Translatable.

Just as a POC I've started the work with Timestampable. The tests are running, but I have not tried it for real as of yet.

https://github.com/doctrine-extensions

This is of course a huge amount of work, which I cannot accomplish alone, and I think no one should do it alone. We should make sure that the project has enough contributors first. A backer company would also be nice... but I guess that is just a dream.

So, thats about it... what do you think?

Adam

[l3pp4rd]

Hi @Padam87 rewriting extensions is huge work. I haven't been using PHP almost 3 years now, mainly java, c and go now and probably no longer will contribute to the project apart from vital bug fixes in this repository.

My personal advice to anyone who will start refactoring extensions, to do it in steps and small releases. One extension at a time. Taking whatever is good from here and rethinking it. If you try to redevelop entire project at once, most likely there won't be enough motivation to keep going, so do it in small steps and release as often as you can. (extensions started only with one behavior and it has grown in time).

Also I suggest to support only ORM not ODM. for odm it should be very different since it is a different type of database. Concentrate on simplicity and easy of use, for users to adopt it, it has to be as simple as these extensions were or even more. (just adding an annotation or replacing it). Instead of various configuration options, allow better to extend the listener and override things, it will be much more flexible, better to write a guide how to extend it with various functionality instead of introducing configuration (that confuses people and makes it hard to learn)

[Guite]

Maybe it would be possible to merge this together with/into https://github.com/KnpLabs/DoctrineBehaviors (don't know about whether and how easy this would be possible though).

[Padam87]

@l3pp4rd I would not say rewrite, but refactor. The first step should be the split. That would be a huge step forward. No one is willing to take on the responsibility to maintain this project, but someone may say "Hey, I can look after Sluggable". And that is what this projects needs the most. Manpower.

After that, we could start upgrading to PHP7, releasing a new major (per extension) and improving quality.

To the only supporting ORM part: This is an interesting take. If only ORM support is needed, we could drop all the wrappers and adapters, and simplify everything. Timestampable could be just a simple listener! That would make things much easier.

@guite: I like KNP's version of translatable better, and we could adapt geocodable too...

[andrewtch]

I suppose that another transition to some other repo would be a messy solution. Also, about splitting - Symfony lives in one monolytic repo just fine.

Refactoring & upgrading is what is needed here.

[Padam87]

@andrewtch Symfony is a very different project. Yes, it is developed in a single repo, but it is split to many components. This split is one of the keys to it's success. Don't forget, symfony components are even more widely used than the framework as a whole. Sometimes you only need a couple of components. The same is true here.

The other main advantage is BC breaks. Maintaining a big open source project is hard work. You cannot release a new version because extension X has changed an interface. It requires a lot of organization. For example, there are a lot of great features in the 3.0 branch, which will be lost forever.

Symfony is different, because the project has resources. Manpower. They can afford to do this. Just because a big corporation does something, and it works well for them, does not automatically mean it would work for small business too.

[andrewtch]

@Padam87 , I kinda seen Symfony developing from ugly ROR clone to a modern state. In fact, I made my first pull request 11 years ago and still contribute from time to time, and I may say that "rewrite everything" is not an option in almost every case.

I may see a path of releasing 2.5 / 2.6 as cleaned - up, 7.2+ library, and then starting developing 3.0 branch to be in sync with doctrine 3.0. I can dedicate some time (30min - 1h each day) to this task, as many projects I'm managing currently depend on this library a lot.

@l3pp4rd , what do you think? 2.5 as a 7.2+ rewrite and bugfix release, and then slowly moving forward? I can help, if we can come up with solid refactoring targets list / release plan.

PS: Hello from Latvia here)

[LucileDT]

In my point of view, splitting the different extensions would be more user friendly. Not everyone need all of the functionalities given in this project, splitting would allow users to take the different extensions they need and only those ones ; and the documentation would be clearer because specific to each extension. I totally agree with @Padam87 on the modular approach. Besides, like @l3pp4rd was saying, it's easier to keep the motivation when we update things by small releases. Splitting the existing project in separated modules would make the thing a lot easier because releases would be specific to each extension. I would like to add that the management of the Symfony project is not comparable to the management you need with the DoctrineExtension project: you're not the same size of team nor project, so I disagree with the @andrewtch statement saying you should take example on the Symfony project management. Yes transfers to other repositories are mainly messy but it's often because of lack of communication around the migration/forgetting to edit the user documentation. Furthermore it's not because it can be messy that you need to avoid it at all costs.

I use GitHub organizations, it's convenient for this use case in my opinion. With an organization specific to those extensions (named e.G. DoctrineExtensionsTeam) and a repository for each of them (slug, translatable...), it would be easy to centralize the main information about the project, the different extensions and how to contribute.

About dropping deprecated dependencies/update the whole thing to PHP7.1, I don't have any opinion, I never contributed so I don't know if it's difficult/useful.

[andrewtch]

@LucileDT , I have one point about monlytic repo - there are lot of cross-dependent tests in Doctrine Extensions (tree + sluggable, or translatable + sluggable), and having them in separate packages would make testing and creating packs for symfony / laravel / you nave it - very complicated.

It's not the size of the team, it's dependencies and tests. Monolytic repo does not force any release schedule, you can focus one moth on Translatable only and then move to another extension.

[LucileDT]

Oh ok sorry, I didn't know there was so much dependencies between the extension tests... :confused: Why is it the case?

[andrewtch]

@LucileDT , because people use them together ) and you have to be sure that Sluggable works ok on Tree that is also Translatable. Simple use-case - translatable slugs for categories.

Such testing would be impossible in separate repos.

[Padam87]

A simple require-dev would fix that...

[andrewtch]

@Padam87 , which repo should contain the integration tests for three plugins? How are you planning to manage PR's that influence 2-3 repos?

This is because symfony selected the strategy of subtrees )

[Padam87]

That is also a non issue. The tests are separated into folders already.

[wshafer]

As a user of this package, I'd be happy to step up and help maintain the project.

I also love the idea of separating out the extensions into a separate packages. For those that want the whole thing, a meta package could be created, if needed. Much like the php-cache project.

I've only ever used the timestampable extension, so it'd be nice to only have to install that one.

As for splitting out test cases that are testing multiple extensions, that doesn't sound like a deal breaker to me as that should be done anyway, shouldn't it?

I am however NOT in favor of a complete rewrite. A refactoring approach is a much better plan forward.

[wshafer]

@Padam87 If you want to create the repos for the extensions I can start splitting them out

[danielchodusov]

Hi guys, any updates about splitting extensions?

[AkenRoberts]

+1 ready to contribute. @Padam87 @wshafer Let's get this started using the organization Adam created. I got the domain!

Would recommend following the model of The PHP League, where packages are maintained and contributed to individually, but kept organized under a common name with common standards. Documentation can be centralized.

As an organization, I'll echo the recommendation to refactor instead of starting from scratch. The existing packages can benefit from splitting, standardization, additional documentation, and issue/PR maintenance without touching functionality. Then, things like ORM/ODM can be split or removed, PHP 7+ feature bumps, new features, etc.

+1 to splitting packages, also. It allows for faster development and release cycle by many developers. Symfony has a long history and standardized dev/release cycle to get away with that. If the biggest hindrance here is integration testing, that can still be achieved with separated repositories.

I'm happy to spearhead this initiative with anyone's help. Would love to take @Padam87's start with the Organization and go from there! Who's on board?

[Webonaute]

@supersmile2009 and I can join the effort. We are using Softdeleteable, sloggable, timestampable, and sortable in our project and currently looking to refactor those feature for sf41 and php7+.

[AkenRoberts]

Wonderful. My biggest headache is Tree (specifically nested sets) right now.

I'm guessing the three you mentioned are the most used extensions. Would make sure to have them updated as soon as possible.

[l3pp4rd]

@andrewtch I also would suggest to do it in small steps and refactor it in small parts at a time. This may be boring and as history shows, not many contributors were interested in that. @Padam87 you are saying this is not refactoring, but it will always end up as refactoring, if you maintain software, it has to be refactored from time to time, changing API as less as possible of course. But the fact is, when people will build a new repository, they will want to refactor things all the way down. You will always find how to make something better. And my point was, just do not take too big steps, you may lose the motivation very quickly.

I can add you all to project contributors, many people are used to this repository, or we can agree with @Atlantic18 to migrate it to different organization, since they seem like not contributing at all. You all may start from version 2.5 or 3.0 changing one extension at the time or working on separate extensions as contributors. Just be careful and do not end up like python 3.0 if you change the interface too much, people may stick with v2.4.

[AkenRoberts]

Moving this repository to the new organization would be really useful - would allow new maintainers to be in full control of any replacement/deprecation process, and keep the history and issues intact.

I would not suggest adding a bunch of new maintainers to this single project without someone in charge of the release process who clearly outlines how to contribute and how releases will work.

[andrewtch]

I see no actual point in moving this to a new organisation. Lots of people will join, many will drop and eventually it will be abandoned (or there will be three packages, one for Gedmo, one for Atlantic18, one for TheNewOrg).

Also, I see no point in splitting the packages, again. I just imagine the config:

doctrine_tree:
    enabled: true
doctrine_sluggable:
    enabled: true

etc.

Finally, I see no goal now. What are you trying to achieve? Just "rewrite and refactor" everything, for the sake of moving code lines around? What is the roadmap? Who will fix the issues? Will you just get the same bugs, but now compatible with 7.1+ only?

A lot of questions are unanswered. @l3pp4rd , what's your current capacity in supporting this?

[supersmile2009]

I think splitting package into smaller ones is a good idea.

It ill allow us to optimize things, bump dependency versions independently etc. Or imagine if doctrine 3.0 brings such changes so that it's impossible or too hard to keep DoctrineExtensions 2.4 compatible with doctrine v2.2 - v3.0 - again we can update extensions independently if we split them. Some extensions will be updated faster, because they are used more people, some will take more time. But we will not be constrained by the need to update the whole set of extensions at once. Even if @l3pp4rd adds a few people as contributors to this repo, they probably won't have enough time and motivation to update and properly maintain all of the extensions. On each package we can have contributors, who actually use them and therefore are interested in maintaining them. Not so many people would be willing to take responsibility for a big project like this, but they may be OK with taking responsibility for a separate extension.

As for the integration tests @andrewtch has mentioned - the best option would probably be symfony-like way using subtree system. So we can have one main repo, which runs all tests, and subtrees which are pushed into independent repositories per extension. It seems there's a service for it - https://www.subtreesplit.com/ or we could use one of the various existing scripts.

[andrewtch]

So maaaaybe let's add maintainers here, bake a roadmap an start with smaller changes? )

[AkenRoberts]

I see no actual point in moving this to a new organisation.

The Packagist info and install process can remain the same while moving the repo to a new organization. The largest benefit I see is putting the repo fully in control of new/active maintainers. I'm also a fan of the more generic topic namespace, though changing that in the code has downsides for an existing project.

Also, I see no point in splitting the packages, again. I just imagine the config

That is an understandable concern. I don't have much Symfony experience, and it's very common for multiple extensions to be used simultaneously. If it adds a lot of overhead for some projects, that's something to be aware of.

So maaaaybe let's add maintainers here, bake a roadmap an start with smaller changes?

I'm totally on board starting here. It's going to take some reorganization and planning regardless of where the repo lives. Let's get some fresh faces involved and see where it goes.

@l3pp4rd Officially requesting contributor status :)

[l3pp4rd]

sent the invites with write access to probably everyone in this thread. I think if you find a way to create an organization, I think @Atlantic18 will agree to move the repository there. I can open this discussion with them anytime. For now, it can be refactored in smaller steps or prepared in some ways

@supersmile2009 it can be split. and this repository may be made read only at some point. Making such changes too fast, may lead nowhere because of user adoption process and time

[andrewtch]

Oookey, we are collaborators now. Thank you, Gedeminas!

I propose:

• cleaning up current task / pull request list, fixing current bugs and merging them to 2.4
• after that, slowly refactoring master to 7.1+ support and doctrine 2.5+ support
• when this is done, master will become 3.x

We should split extensions between people - please comment below who is interested in supporting particular extension.

We should also have Slack - please comment what is better for you, having separate channel on symfony support or separate slack? If wee agree on channel in official symfony slack, send your slack names or just join #doctrineextensions

[wshafer]

I think before we start we need a consensus on splitting out the extensions or not. I’m a fan of doing this and think this has benifits for both consumers and maintainer.

I have no opinion on the organization these repos live under, makes no difference to me. Same goes for the slack channel. I like the idea of a development channel I just don’t care what org it lives under.

As it seems like more people on this thread are interested in breaking this apart I’d like to purpose a modified roadmap to @andrewtch

• cleaning up current tasks / pull requests list <- this should be done before any splitting of the repos. Why loose all the valuable work that others have already done?
  • cleaning up the issues list and identifying tickets that need addressed. Noting them for work for 2.4, to be addressed on 3.0, or closing out issues that won’t be done.
• releasing a 2.4 version
• begin seperatating the extensions
• add support for Doctrine 2.5 and php 7.1+ support
• tag and release extension with 3.0 as that extension becomes ready. <- with these being separated no reason to wait for the whole set to be complete now that these can have have their own versioning.

Thoughts?

[wshafer]

Random thought. If we do split this into smaller packages, this repo could simply become a meta package for users who already have this installed. Might make the migration a little smoother for users who don’t follow this package.

[AkenRoberts]

We should leave the monolith as-is for now, with the possibility of duplicating extensions to their own read-only repository packages. There are too many new variables and existing issues/PRs to triage before we even think about completely splitting apart contributions.

[AkenRoberts]

Regarding Slack, I have joined Symfony's organization and #doctrineextensions. I think having a dedicated channel on an existing, well-populated Slack is better than a separate Slack login.

[AkenRoberts]

Thank you all for expressing your interests, and for those who have joined me as new collaborators ready to do something. 😉

We're ready to start taking action. I encourage all collaborators to start triaging open issues, putting together to-do and wish lists for upcoming minor and major releases, and start to formulate a plan. I will be relying heavily on your assistance and talents.

Onward!