Hi all,

>I'm squarely in the "move 'em out, tag 1.2, call it a day" camp.  I think
any
BC concerns are over-exaggerated unless demonstrated otherwise, and even
then
fixing it for anyone affected is a single `composer require` statement.

+1. I doubt anyone is depending on them, and the consensus seems to be that
they shouldn't have been put there in the first place.

R

On Tue, 11 Dec 2018 at 19:03, Larry Garfield <la...@garfieldtech.com> wrote:

> Util packages have, I think, been using Fig\ as the top level namespace
> segment, not Psr\.  At least they're supposed to be... :-)
>
> I am not too bothered if we use the *-util package or start a *-tests
> package
> for this sort of case.  But either way, they're not part of the spec and
> so
> should never have been in the repo.
>
> I'm squarely in the "move 'em out, tag 1.2, call it a day" camp.  I think
> any
> BC concerns are over-exaggerated unless demonstrated otherwise, and even
> then
> fixing it for anyone affected is a single `composer require` statement.
>
> --Larry Garfield
>
> On Tuesday, December 11, 2018 7:39:05 AM CST Chuck Burgess wrote:
> > 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 <ras...@mindplay.dk>
> 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 <alessandro.la...@gmail.com
> > >
> > > 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 the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/9682261.mGdNde0gT2%40vulcan.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Robbie Averill | Senior Developer
04 978 7330
http://silverstripe.com/

-- 
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 php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANv6TC0Mfy6RSFij0-sCL2iJab4QUpHoZmeJxdLeovVugT1fJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to