The road to 3.0

[jubianchi]

Everything in the following list is under discussion, feel free to send feedback on anything. Additionally, If you see something missing, please tell me.

• [x] Require a higher PHP version (at least >= 5.6) (#643)
• [x] #646 - Require a higher xDebug version (>= 2.3.0) and add it to suggest in composer.json (#651)
• [x] #653 - Remove all code relying on method_exists
  • [x] in mageekguy\atoum\factory\builder\closure::isVariadic()
  • [x] in mageekguy\atoum\mock\generator::getParameterType() (line 699)
  • [x] in mageekguy\atoum\mock\generator::isVariadic()
  • [x] in mageekguy\atoum\php\mocker\funktion::getParameterType()
  • [x] in mageekguy\atoum\score\coverage::getDeclaringClass()
• [x] #647 - Remove all tests that are not relevant on the minimum PHP version (< 5.6) (#657)
• [x] #647 - Remove PHP version filter where it target >= 5.6 (#657)
• [x] Remove all PHP versions that are not relevant from CI (#643)
• [x] #648 - Remove deprecated methods (#650)
  • [x] mageekguy\atoum\asserters\dateTime::isInYear()
  • [x] mageekguy\atoum\asserters\dateTime::isInMonth()
  • [x] mageekguy\atoum\asserters\dateTime::isInDay()
  • [x] mageekguy\atoum\asserters\stream::isWrited()
• [x] #652 - Remove deprecated CLI flags (#656)
  • [x] --test-all and its handler (in mageekguy\atoum\scripts\runner, line 1014)
  • [x] mageekguy\atoum\scripts\runner::addTestAllDirectory()
• [x] Merge #615
• [x] Revert 9c6772ad6: closure are bound to te current object context, no need to pass the test instance anymore
• [x] Remove all $this assignation that are only for closures uses (#658)
• [x] #645 - Remove all code relying on version_compare (#649):
  • [x] in mageekguy\atoum\autoloader::exists() (5.4.0)
  • [x] in mageekguy\atoum\asserters\dateTime::isImmutable() (5.5.0)
  • [x] in mageekguy\atoum\asserters\dateTime::isDateTime() (5.5.0)
  • [x] in mageekguy\atoum\test\adapter\invoker::isBindable() (5.4.0)
• [x] Move fancy reports to the reports-extension (santa, nyancat, logo, ...) (https://github.com/atoum/atoum/pull/644 / https://github.com/atoum/reports-extension/pull/26)
• [x] Apply PSR-1 and PSR-2 (#642)
• [x] Make atoum\atoum the real root namespace and alias it to mageekguy\atoum
• [ ] Extract builder, pusher and other tools to a dedicated repository
• [ ] Add a test on mock auto-binding (in tests/functionals)
• [x] Add a generator asserter: (#664)
  • [x] with a yields assertion
  • [x] with a returns assertion (PHP >= 7.0)
• [x] Write a UPGRADE guide (#697)

  Experiment / Discuss

• [ ] Extract asserters to a dedicated library atoum/asserters to ease reuse in other tools (Behat for example)
• [ ] Extract the mock engine to a dedicated library atoum/mock to ease reuse in other testing frameworks
• [ ] Replace all \closure typehint with a callable typehint
• [ ] Make the test namespace configurable without having to extend the base test class
• [x] Write an Homebrew formula
• [x] #694 - Extract the VIM plugin to its own repository (atoum/vim-plugin)
• [ ] Extract the Phing task to a dedicated library/repository (#654)

[Grummfy]

615 I'm not sure we need to wait before the end of 3.0.0 before releasing something, even is something called atoum-2-fixed-for-7. We can at least provide something downloadable.

Thing to questions:

• [ ] interest of the --test-it in the phar ?
• [ ] for the compatibility, shouldn't we add an alias for the namespace?
• [ ] splitting atoum and extracting mock motor (easier to use with other tools)
• [ ] removing builer and other stuff that are not mandatory to let atoum run

[jubianchi]

Thanks for your feedback @Grummfy!

I added some things you proposed to the list.

I'm not sure we need to wait before the end of 3.0.0 before releasing something

No, we won't wait until the end before releasing. We will be able to issue beta releases when we want thanks to the #640 ;)

interest of the --test-it in the phar ?

This is useful when someone downloads the phar, he can quickly check if everything is OK on his PHP setup.

[Grummfy]

by the way I think we should add some extra stuff to help contribution like a phpcode style checker

[Hywan]

@jubianchi Did you think about PSR-2? Just a simple thing to ease contribution I guess… It completes the proposal from @Grummfy.

@jubianchi Also, extracting asserters and mock engine into standalone library is a really good thing but it would introduce a lot of work. So I propose to postpone this work. It would not introduce any BC break in the future because the public API will not change. It will simply consist to plug things together.

So my opinion is +1 for everything except the library creations that can be an asynchronous work.

Thoughts?

[jubianchi]

@Hywan I was thinking about adding PSRs for coding-style but did not want to start a troll or something. If you think we should add it, I'm OK.

Extracting asserters and mock engine is something we should try during the 3.0 development phase. If it's too much work, I'm OK to postpone this. If we can get this done for the first 3.0 stable release (yes we will probably run through some betas before the stable release) I will be happy :)

[Hywan]

@jubianchi The 3.0 release is required by major projects for PHP 7 compatibility (like Hoa or Pickle). So I propose to postpone it, since having new libraries for asserters and mock will not introduce any BC break. It will just take time and the 3.0 will be delivered late…

About PSR-2, I am in favour of it. We can use PHPCSFixer with some custom rules if we want to. Would you like me to do that?

[jubianchi]

@Hywan if I were to adopt PSRs for coding style , I would donit without any specific rules. I think a well-written configuration file could be enough.

For asserters, we have no hurry but we have to try to split them for the 3.0. If wait we might end up introducing another BC breaks. One I can think of is that some class might disappear from atoum itself.

[Hywan]

@jubianchi I think we should define a deadline so. Any proposal?

[jubianchi]

@Hywan we should ensure the scope is Ok and we have nothing to add that could introduce a break.

Once we are OK with that, we'll try to define a deadline.

[Hywan]

@jubianchi OK. Should we plan an IRL meeting for that or does someone come with a first draft proposal?

[jubianchi]

@Hywan as we will probably release some betas I think we should just start implementing some of the items

[mikaelrandy]

@jubianchi i like your proposal, but i ask myself about release management in atoum. Originally, we choose to separate development and release management. @Hywan and me just regularly look about merged PR to define if it's major, minor or fix release.

With this proposal, i think @atoum/rms have to define a new release management with predefined scopes.

[jubianchi]

@mikaelrandy I don't think the release process will change much: to me we will still be pushing PRs for items in this list and release betas until we have everything done. We will then publish a stable 3.0.0 release.

[mikaelrandy]

@jubianchi as we just have a unique master branch, we cant release 3.0-beta releases and 2.x in same period. We should have a 3.0-dev branch.

[mikaelrandy]

My bad, i just see it's already a 3.0.0-dev branch !

[jubianchi]

In the #642 @Hywan updated the command to detect xDebug. This made me think of one thing: should we also require a higher version of xDebug ? something like >= 2.3 (2.3.0 being the version in which branch and path coverage was introduced) ?

[Hywan]

@jubianchi I agree with 2.3.

[Grummfy]

2.4, no? because of the lot of segfault bug?

otherwise, it could be intresting to create small issue to see if we can help, because honestly I don't really see How I can help here

[Grummfy]

Thanks for creating easy pick issue ;)

I have created the #654 for phing ;) (not so easy because, if I'm remembering well we have some check, perhaps a bit of refactoring will be required on this one)

I have a question about "Extract builder, pusher and other tools to a dedicated repository" I know that some stuff not really working anymore (the phar building part), so we just extract them or we also remove useless parts? I'm not sure we can really easily do this without being in the release team or in the core team (aka someone who really knows the stuff), but perhaps you can give some indication that let us help you?

If we can do something, don't hesitate to create task. I know that sometimes it takes almost the same time to create the task and explain it, but you know that when someone doing it, you are happier after that because you got help. ;)

Thanks for the great job already done, you rock people!

[shouze]

ok, I've read the roadmap and it's almost done, can't some non urgent thing could be postponed to other updates?

Only split of some parts in other packages/repos seems to miss for a 3.0 release in fact.

This would bring full support for php 7.1 this way.

[Hywan]

What feature(s) would you like to bring into 2.9 and frontport to 3.0?

[shouze]

In fact I think it would be great to release 3.0 right now - as is - and complete other tasks in further 3.x releases, no?

[shouze]

This could be a 🎅 🤶 🎁

[Grummfy]

AS I said several time we should publish 2.9.0, merge all change in the 3.0.0 and publish as it is. and working on version 4 to do all we require to do. Otherwise we are blocking ourselves

[omansour]

cant wait ! especially to use php7.1 with atoum

[jubianchi]

@omansour I'm working hard on finishing current releases. I hope I'll be able to release soon.

Really sorry for the loooong delay

[omansour]

no pb, that's not so long at all. I'am available to test any beta or RC.

[tyx]

Same here, we are available to test pre-release !

[shouze]

Yes, tell us how we can help.

I guess many of us don't have many time to spend but if you can assign us on quick win issues to complete the release process.

It would be so cool, as I've encountered today again another case where php 7.1 features would have been nice to use.

[mikaelrandy]

I've asked @atoum/core about this release date, and i will release a 3.0-beta version really soon.

Stay tuned ;)

[mikaelrandy]

Tadaa, atoum v3.0.x-dev is available : https://packagist.org/packages/atoum/atoum#3.0.x-dev

Please keep in mind that is a beta release, that could change at any time, without warning, and could introduce major BC break as it a major version.

[Grummfy]

Otherwise, you can always check into the huge todo list present here the related issue. If nobody working on it, you can take one ;) some are just code extracting (like phing).

[vdechenaux]

Any news for PHP 7.1 support in a stable package ? :)

[Grummfy]

For now it will be a beta version. But you can use it like if it's stable. It's its internal api that can change.

Le 10 févr. 2017 09:12, "Vincent Dechenaux" notifications@github.com a écrit :

Any news for PHP 7.1 support in a stable package ? :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/atoum/atoum/issues/641#issuecomment-278883011, or mute the thread https://github.com/notifications/unsubscribe-auth/AAo0hFxYZkjoSio5XtxdOEIvWu7wN128ks5rbBvPgaJpZM4KLsJF .