With the util libraries, I'd concur with Matthew. Right now it is kind of undefined I agree but I also am not sure that is necessarily an issue to be honest. What is the problem solved by creating formal processes around the util libraries?
You call out simplecache-util, I don't think the problem there is a lack of formal process for util libraries. It appears to either be that it's just not necessary/no demand for anything there or nobody is willing to put the time into doing it. I don't think a formal process is the answer there? Also, most of the util libraries need very little to no maintenance as they are designed to be kept simple and uncontroversial. Maintaining a group around each of those seems quite heavy and probably would result in more time spent on the admin than the actual project itself. I think conceptually something like what is proposed [PERs] make sense for things like coding standards but I would note that it is also very helpful to be able to clearly delineate versions and call out that one is meeting a standard (PSR-12 or PSR-2). Nobody wants standards to be... too fast moving or agile, perhaps a version a year at maximum velocity for example. So perhaps when establishing a PER there is a defined maximum release schedule velocity and a strict scope of what 'evolution' looks like (e.g. stuff is only added due to new or mutated PHP functionality, to clarify, or to reflect changes in the ecosystem for coding standards, not just add whatever you wish whenever you want). I also think backwards compatibility [in the sense of not changing things but only being additive as any standard change is a BC break in the usual sense of the word] and simplistic versioning (e.g. PER-CodingStandards V1, V2, V3 where they are additive or clarificatory, not mutating) I think would be critical to the success of the idea of PERs, over something like semantic versioning which automatically implies three levels of versioning and the idea of "BC" breaks. I can't see people wanting to be maintaining automation tools or projects that are dealing with a standard that is being updated too frequently or has complex versions determining which versions of the standard are supported (tooling) or which version is implemented (projects). Many thanks, Michael On Fri, 13 Aug 2021, 17:27 Larry Garfield, <la...@garfieldtech.com> wrote: > On Thu, Aug 12, 2021, at 10:42 AM, Matthew Weier O'Phinney wrote: > > My main question is why the Util libraries would move to the PER process. > > > > Currently, these have been developed to provide features complementary > > to a given standard: > > > > - cache-util and simplecache-util provides boilerplate that will be > > used in most implementations, as well as default "in memory" > > implementations. > > - http-util provides constants used for request methods and response > > status codes > > > > In each case, I'd argue they're less "evolving standards" as they are > > libraries tracking common usage or tracking non-FIG standards to > > provide commonly used artifacts. In other words, they are _libraries_, > > not _recommendations_. > > > > Otherwise, the rest of this looks fantastic! Thanks for putting this > together! > > Mainly because right now we have no process for util libraries; their > ownership and management is entirely undefined (as witnessed by the > simpelcache-util library being entirely empty and abandoned for no > particular reason). I figure if we establish a process for them it would > probably look an awful lot like the PER process, so I tossed them in > together. > > If we wanted to keep them separate, what would that look like? > > --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 view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/0a7fec5a-864d-4b44-b24b-717d9e7e3343%40www.fastmail.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 view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAnq%2BP-ef5hnd9M32Hg9kiK5Gu7YswqYc6bCytF4DB7nmG6tpw%40mail.gmail.com.
