Zend Dom and standalone

[harikt]

Hi ,

Considering the removal of stdlib #5865 and the package has become truly independent will you be considering to move the tests also to https://github.com/zendframework/Component_ZendDom , so people can send PR or can create issues at https://github.com/zendframework/Component_ZendDom .

I was looking at ZendXML and thought of this.

Thank you.

[Ocramius]

@harikt that is not possible and would make it impossible to manage the component/releases together with the framework.

The component packages are generated from a subtree split and are to be considered read-only.

[harikt]

@Ocramius how does https://github.com/zendframework/ZendXml works ?

It is not a subtree split according to my knowledge ( Looking at the commits ) .

So I was asking whether the tests can also be moved like the https://github.com/zendframework/ZendXml .

[Ocramius]

@harikt moving the component out of ZF2 and into a separate repo would require making ZF2 require zendframework/zendframework depending on zendframework/zend-dom for consistency (or break BC).

It can be done, but I'm not sure if it is worth it. It would only make things harder for maintainers that would have to hop back and forth through repositories.

I'd personally prefer to have the issue stay in the main repo to be able to track them in a meaningful way.

What is the big deal with moving them out? What are the main advantages?

EDIT: yes, ZendXml is out of the main repo itself, looks like a new project though.

[harikt]

@Ocramius I don't understand how it requires zendframework/zendframework . In zendframework/zendframework composer you can add he zendframework/zend-dom according to my knowledge.

Moving to a separate one means tests and PR need only done to the same repo. Just a suggestion as I see ZendXml.

[Ocramius]

@harikt no, what I mean is that users upgrading and using the component would either need a new additional package or be forced to get (transitively) a new package.

I just don't see the benefits tbh - if you have a subtree split of the existing package that provides you with the reduced zipball etc etc, then why not just keep it as it is until 3.x if needed?

There must be stronger reasons to drive such a change in my opinion. It is just going to be more problematic with documentation, releases, consistency with the fw and most probably would just be forgotten in a corner.

[Maks3w]

Sorry guys. Issue tracker is not the best place for take this discussions. Better use the mailing list