On Tue, May 16, 2023, at 2:26 PM, Derick Rethans wrote: > On 15 May 2023 13:38:56 GMT-05:00, Larry Garfield > <la...@garfieldtech.com> wrote: >>On Mon, May 15, 2023, at 6:36 PM, Rowan Tommins wrote: >>> On 15 May 2023 09:54:41 BST, "G. P. B." <george.bany...@gmail.com> wrote: >>> >>>>Why are we assuming that PHP 9.0 is going to come after PHP 8.4? >>> >>> Historically, PHP has had a major release roughly every five years. The >>> main exception is PHP 6, which was never released - but whose major >>> features became PHP 5.3, five years after 5.0, and six before 7.0 >>> >>> I think planning a rough timeline is more useful to users and >>> contributors than waiting until there's some exciting headline feature. >>> Otherwise, it becomes tempting to sneak in breaking changes in 8.x >>> because "we don't know how soon 9.0 is", or to have a rush of changes >>> because "we've only just decided 9.0 is soon". >>> >>> It also helps avoid putting a release number on an experimental feature >>> that might never arrive, as with Unicode strings in 6.0; or that might >>> turn out to be less important to most users than other changes, like >>> the JIT in 8.0. >> >>I agree entirely. Setting reasonable expectations for users to plan around, >>such as a known 5-years-per-major cycle, helps end users far more than >>"whelp, we did something big, version number time!" >> >>Tangent: If I were to put together an RFC that set out such a 5 year cycle >>expectation with reasonable guidelines around when things could be >>deprecated, would anyone actually support it? >> >>--Larry Garfield >> > > I would. With some remarks. > > I think that having a 5 year cycle for major releases is beneficial. > > First to users as they know when all the deprecations are being rolled > up into behavioural changes and (potential) breakage. > > But also to us, as maintainers, as it could signal *when* it makes > sense to work on deprecations, behaviour changes, and code refactoring > (that's more likely to break APIs and extensions). > > IMO it would make sense to tweak what sort of user land deprecations > can be done in the .3 and .4 releases (probably being more strict) > compared to the .1-.2 releases. We'd want to enlarge thr time frame for > significant changes more ahead of time compared to more minor ones. > > But I do think we ought to be weary of making these rules, in when to > allow to deprecate what, too strict. A rough set of guidelines makes > IMO more sense. > > cheers > Derick
What would be a reasonable heuristic for "gotta do in .1 or .2 to give people time" deprecations vs "this is minor enough that it's OK to do in .3 or .4" deprecations? "Amount of code impacted" is not great, as that's extremely hard to determine (as we've seen). But I'm not sure of a better metric. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
