Is it possible to mark future PHP versions as untested but available in Composer?

[JakeQZ]

We restrict PHP version to the current latest.

But if we could in some way allow a later version under certain conditions, marked as 'use at your own risk', that would, I think, be helpful to both us and developers using our software.

Recently, support for the latest PHP version has simply involved a change to the maximum PHP version in composer.json. But we have to provide a new release to support it. And some folk have raised issues because we haven't yet done that, and they are unable to test aginst, say, the next PHP alpha.

My rationale here is ZCO (zero cost of owenership) - we shouldn't have to keep making new releases if there is no change in the software - it's a waste of everyone's time.

[oliverklee]

For our released version, we should keep having the lower and upper PHP version boundaries. That's because Composer will use it to automatically find versions of the requested packages that match the current PHP version and the other dependencies.

We can however create a "use at your own risk" branch that has no upper PHP version boundary, and that automatically gets rebased when the main branch gets updated. I can set that up.

What do you think, @JakeQZ?

[JakeQZ]

I think it would would be good if 'early-adopters' could test our software against the next version of PHP

This would benefit us, because any potential issues could be found early.

We can however create a "use at your own risk" branch that has no upper PHP version boundary, and that automatically gets rebased when the main branch gets updated. I can set that up.

If it would not be too much effort, and there are no better alternatives, this may be a good idea.

I am seeking to minimize maintainance effort from all parties. If we think this achieves that, then I'd say "go for it". But if it in turn adds an extra maintanance headache, I'd say not. I have found GitHub to be somewhat disappoiting of late, requiring more maintanance from users than should be expected. In an ideal world we wouldn't be hindered by GitHub's limitiations.

[oliverklee]

I have now created #1210 for this and will implement this in the next weeks.