Comments (23)
Yes : let's drop travis and use github actions.
from cfpropertylist.
Hi
Ok, agreed : so no new major version needed. By the way, I forgot that releases 2.x were created after I splitted all classes in their own file. Therefore the branch support/1.0 is useless. My bad. I'll rebase your PR onto develop before merge, and both support/* branches being now useless, i'll delete them.
from cfpropertylist.
Hi
I fully agree with your point of view to prefer approach 2 and drop PHP 5.6 support. If you want to do a pull request, go ahead. I'll prepare a new major version with this change.
from cfpropertylist.
Alright, sweet. So to some up, I will:
- add the missing type hints for the
Iterator
andArrayAccess
methods - require at least PHP 7.4
- possibly bump the required versions of certain dependencies (like phpunit)
Sound good?
from cfpropertylist.
Yes, it looks good to me.
from cfpropertylist.
Great. Slightly off topic. Would you be open for a separate PR that adds a Github action to run the test suite against different PHP versions? I found this issue (#44) but it's from 2018 and there doesn't seem to have been any activity on it since then.
from cfpropertylist.
I've run into a slight issue while adding the return types. The mixed
type has only been added in PHP 8.0, so it's not possible to add it as a typehint without having to drop support for PHP 7 completely. Not adding the mixed
type hint still causes a deprecation warning, unfortunately.
So I guess there are two options:
- Use as many typehints as possible and fall back to
#[ReturnTypeWillChange]
wheremixed
would be required. Feels kind of icky since we're back to square one, more or less. - Require at least PHP 8.0
I definitely favor option two (especially as a maintainer), but completely dropping PHP 7 is definitely a bigger change than dropping PHP 5.6.
That being said, since we wouldn't be adding any features, it's not like people who don't use PHP 8 and up would have any reason to update anyways.
from cfpropertylist.
https://www.php.net/supported-versions.php
I think It is too early to drop PHP 7.x support. Maybe it is time to have a dedicated branch for each major version (current and curent +1) to permit maintenance of both for some time.
from cfpropertylist.
In that case I would tend towards using the #[ReturnTypeWillChange]
attribute instead of mixed
and keeping everything on one branch. The branches would be literally identical in features, they would only differ in some of their method declarations. I don't think this is worth adding the maintenance overhead of two separate versions.
But it's your decision, of course.
from cfpropertylist.
The branches would be literally identical in features, they would only differ in some of their method declarations
Yes, but semver says a new major version should be created when there is a breaking change : https://semver.org/
8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.
Then maybe this would not be a problem to create a branch for 2.0.x . Also, there is few activity on this prroject, then there should not be much overhead to have a new branch and still maintain 1.1.x at least 1 or 2 years.
from cfpropertylist.
That still leaves the question about whether the 2.0 branch should require PHP 8 and up or not. Otherwise we'd still have to fall back to using #[ReturnTypeWillChange]
.
from cfpropertylist.
I would propose to create a branch support/2.0 for a PHP 8+ version and an other branch support/1.0 for 1.X versions.
The names are from Git flow AVH branching model. Without strictly apply its rules, the branch names are understandable.
EDIT : I noticed cross post. Version 2 would support PHP 8 and above only, and version 1.x would still support PHP 7.x. This version could support #[ReturnTypeWillChange] without having issue until PHP 9. By security, we could set a high php version limit in composer.json.
from cfpropertylist.
Ok, then I will prepare two PRs, one for each new major version 👍
from cfpropertylist.
thank you very much for your contribution
from cfpropertylist.
Branches support/1.0 and support/2.0 created. You may base your branches onto them.
from cfpropertylist.
Opened a PR for version 1.0 (#70).
I'm honestly not sure if creating a separate branch for PHP 8 and up is worth it. The 1.0 branch would already work for PHP 8.1. So maybe just keep this one branch around and release a new major version in a year after PHP 7.4 is EOL? Then we could simply remove the #[ReturnTypeWillChange]
attribute and use the mixed
type hint instead.
from cfpropertylist.
I think this is necessary to follow semver recommendation : dropping support for some PHP versons is a breaking change, then the rule is clear, even if this is overkill here. The pro is that you can avoid #[ReturnTypeWillChange] then there is no cleanup for this temporary lines of code (in a few months or years). Also, maybe this gives the opportunity to add more type hinting elsewhere in the code (among others)
I'll study soon the release of the next 1.x version.
from cfpropertylist.
I don't believe that dropping support for a PHP version is even a breaking change. Composer will ensure that the new version simply won't get installed is the PHP version is not satisfied. So there's no danger of a composer update
breaking any projects.
from cfpropertylist.
Some relevant links:
- https://github.com/semver/semver/blob/d460299638d3d2af6fcf809285dc6a469e15742a/semver.md#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api
- https://sebastiandedeyne.com/composer-semver-and-underlying-dependency-changes/
In short, if my application requires PHP 7.3, it will simply not install a newer version of this package that requires PHP 7.4 until my own application becomes compatible.
from cfpropertylist.
Sounds good. Thanks!
from cfpropertylist.
Hi
Tag v2.0.3 created with your contribution.
Be aware that I will probably remove the v prefix from all 2.x tags . I don't have enough time these days to do it right now. I hope the release will help you for your project.
from cfpropertylist.
The tag doesn't seem to be available on Packagist yet. This looks related to an old issue of mine (#65) where the package doesn't seem to auto update on Packagist.
https://packagist.org/packages/rodneyrehm/plist
from cfpropertylist.
Hi
Thanks you for the feedback; i'll investigate this week
from cfpropertylist.
Related Issues (20)
- Add documentation and more examples
- Assistance with example HOT 3
- Packagist package has the wrong name HOT 1
- CFPropertyList Problem HOT 14
- new CFNumber(0) = format error HOT 4
- TypeDetecting Dictionary fails HOT 1
- Error reading large plist files HOT 6
- Maintainers Wanted HOT 12
- Information for project site HOT 1
- DevOps tasks
- HTML-Proofer found 2 failures
- Uncaught exception HOT 9
- How to disable base64 decoding? HOT 2
- Package does not auto-update on packagist HOT 2
- Output of toXML() for <real>s is locale-dependent and causes creation of invalid PList-XML HOT 4
- `CF$UID` cannot be squashed to integer HOT 2
- Can I directly use plist data in variables? HOT 1
- CFDictionary should not allow adding empty keys
- CFType may attempt to call createTextNode with a null value
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cfpropertylist.