At first glance, I think I'm good with moving this out to a log-util package, with perhaps a bump to v1.2. Adjusting testcases has never really urged me into being concerned about versioning, at least when working in my packages. The BC extent of anyone actually depending on these for their own tests should just be a `require` section adjustment in their `composer.json`, right? Namespacing of our other util packages that I spot-checked look like they stick to the namespace of the PSR interfaces that they tie back to, so these classes in the util package would keep their current namespace. CRB *about.me/ashnazg <http://about.me/ashnazg>*
On Tue, Dec 11, 2018 at 5:23 AM Rasmus Schultz <[email protected]> wrote: > As I've noted on the PR thread: > > Introducing the test facilities in the first place was a "bug", and fixing > it will break tests only. > > Versioning that fix as a major is wrong, since there are no breaking > changes to the library itself. > > If you're very concerned about breaking somebody's tests, you could do a > minor release some months earlier with deprecations for these facilities > and a note stating the date by which they will be removed. > > Versioning the removal as a major will create an endless cascade of > dependency issues for something that doesn't affect production code. > > Please no. > > On Tue, Dec 11, 2018, 09:33 Alessandro Lai <[email protected] > wrote: > >> Sorry for adding this with so much little notice. I added that since the >> other one was already present, and that wouldn't change the number of >> implicit dependency on that package. >> >> Obviously not using that class will not trigger any issue, but removing >> that now would be a BC, so I'm against doing that: breaking SemVer would be >> a very bad example here. >> >> I'm all for splitting it into a separate package, but I would like the CC >> input on this, since my previous action seems to be debatable. In any case, >> this would require a 2.0 of psr/log, but I fear that that change would >> scare a lot of people... Even the 1.1 ruffed some feathers! >> >> Il giorno venerdì 7 dicembre 2018 20:23:42 UTC+1, Larry Garfield ha >> scritto: >>> >>> On Friday, December 7, 2018 10:19:45 AM CST Rasmus Schultz wrote: >>> > I noticed the introduction of two PHPUnit-specific test-dependencies >>> into >>> > the psr/log package: >>> > >>> > https://github.com/php-fig/log/tree/1.1.0/Psr/Log/Test >>> > >>> > How is this in any way acceptable? >>> > >>> > The dependency isn't even declared in the "composer.json" file - but >>> that's >>> > kind of besides the point. >>> > >>> > First of all, PHPUnit isn't PHP - introducing facilities for a >>> specific >>> > test-framework is extremely opinionated and does not belong in an >>> package >>> > with interfaces designed to bridge projects and provide >>> interoperability >>> > between different frameworks. (PHPUnit being a test-framework.) >>> > >>> > Moreover, these facilities aren't a dependency, at all - you can use >>> this >>> > package just fine without it. There is no rational reason not to >>> package >>> > these dependencies separately. >>> > >>> > These facilities belong in a different package that depends on >>> psr/log, so >>> > you can version them separately. Stuffing these into the package >>> itself is >>> > extremely controversial and could create a serious problem with >>> versioning. >>> > (having to version the interfaces as 2.0 for a breaking change to the >>> > test-facilities!) >>> > >>> > I'm calling for a bugfix release to remove these ASAP. >>> > >>> > Who's even responsible for this? >>> > >>> > There's no issue-tracker on the GitHub project, and I don't see any >>> > discussion about it in this forum. >>> > >>> > wtf? >>> >>> One of them has been there for years. The other was just added recently >>> with >>> little notice. >>> >>> This has been discussed before, and frankly I agree that the tests >>> should not >>> be in the package at all. We have -util packages for this sort of >>> thing. >>> >>> Related discussion: >>> >>> https://github.com/php-fig/log/pull/52#issuecomment-378323725 >>> >>> --Larry Garfield >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "PHP Framework Interoperability Group" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/php-fig/DsmK600GAas/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/ed94acf6-698c-4410-8b10-44dba2f40ef7%40googlegroups.com >> <https://groups.google.com/d/msgid/php-fig/ed94acf6-698c-4410-8b10-44dba2f40ef7%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/CADqTB_hTs_vzN8raRbcCW0e3S31w%3DGHzno2rixzpzBQUim2-Nw%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CADqTB_hTs_vzN8raRbcCW0e3S31w%3DGHzno2rixzpzBQUim2-Nw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANsgjnvHP0BbNA%3DPGm_4CR9Y5AitoBQVo%2BkuYsORyqrGT6TKig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
