steps for next version - bc break

[Grummfy]

Hello,
as discussed, we have several task to do for a next version:

• increase minimal php version to php 7.1 (require Provide Supported PHP-Versions in all composer.json files #70)
• introduce hoa\Option New library: Hoa\Option #56
• fix for undef(resolve) adding Hoa namespace to resolve to avoid conflict Protocol#22
• update hoa/consistency first, then other libraries,
• something else?

But two question:

• increase php version for the pleasure is stupid, so only if there is a refactoring of the code, for me nothing should be done? which version php 7.0 or 7.1 ? for me it's not clear.
• how does we introduce hoa/option in libs? for which purpose? does we create several task explaining for each libs the purpose?

[Hywan]

Upgrading to PHP 7.1 because:

• It's better,
• PHP 5.x is dead,
• It has scalar type declarations, so we can drop PHPDoc and use Kitab format instead, so use Kitab for online documentation (see RFC Online API browser #53),
• and to test the documentation (see RFC Compile API documentation examples in executable tests #52),
• We can use hoa/option (see RFC New library: Hoa\Option #56), which is an excellent thing for us,
• We may change some method namings (see RFC Simplify getter naming, introduce data conversion naming #54),
• hoa/iterator are likely to change too (see RFC Enhanced Hoa\Iterator API #55).

So, scalar type declarations and hoa/option will introduce a natural BC break. The goal is to combine this BC break with the drop of PHP 5.x, which is implicitely a BC break too.

The plan would be to:

1. Release hoa/option,
2. Update hoa/consistency to use PHP 7.1,
3. And update all the other libraries in popularity/dependency order.

Thoughts?

[Grummfy]

oki but for me, the plan seems correct.

But for me I'm not seeing how to help, on the following points:

• use hoa\Option New library: Hoa\Option #56 : what concretely we must do? can you try to make a issue with detail about it, because for me it's not easy to understand how to help on it
• change about doc Online API browser #53 : for me the Compile API documentation examples in executable tests #52 will rise from that, what did you expect we do?
• Simplify getter naming, introduce data conversion naming #54 can be easier to see what to do

For me, I see nice idea that have been implemented (iterator is precise, option is nice and nearly ready). But about other library impact, I don't see what to do to help on it. Perhaps I miss something.

[Hywan]

@Grummfy Updating the code to PHP 7.1 is something concrete: Adding type declarations, using PHP 7.x new features (remove all the call_user_func for instance) etc. During this process, add new documentation, and use hoa/option where possible. This must be debated but there is no hard rule: Use it when it makes sense. We can split this work in many PR of course.

[Grummfy]

so perhaps we can have a branch for all of these?

[Hywan]

Hmm, not. We can release hoa/option, then release hoa/consistency (with a BC break), then release hoa/exception (with a BC break), then release hoa/ruler (with a BC break) etc. Why should we need new branch?

[Grummfy]

oki. that's fine

[Grummfy]

we also need to drop the usage of resolve() function