[WIP] v1.0.0 / v0.14.0 #253
Conversation
…ties This is because in PSR6 the “set” and new expiration functions are no longer persistent to the driver but instead save data in the object until it is saved. This change provides backwards compatibility (for now) to make testing easier, while providing the foundation of the future changes to this class.
Conflicts: tests/Stash/Test/AbstractPoolTest.php
|
@andrerom if you want to give this another review that would be great. I think it's just about ready for beta testing. |
|
|
||
| * Added `expiresAt` and `expiresAfter` functions to the Item class. | ||
|
|
||
| * `getExpiration` to return current datetime when no record exists. |
There was a problem hiding this comment.
this sound strange, I wouldn't expect a unset expiry to mean it has expired (now). As this is currently not part of the PSR interface, maybe rather return null if none is set.
Otherwise expiry should probably have been on the pool->save( $item, $ttl ) method
There was a problem hiding this comment.
I don't have a problem making this return null- it originally returned false, but when getExpiration was added to the PSR they had their version return the current datetime. Now that it's been removed from the standard we can handle it however we want, so I'll put it back to null.
|
did a quick pass and looks ok, I some logic can be moved from item to pool, but that is a design decision you are free to take afaik. |
|
@andrerom I agree with the pool/item logic issue you brought up, but am focusing right now on the external API for this PR with the idea that we can continue making improvements to the internals even after this release. |
This should solve ##274.
Fix issue with different constructor for APCu
|
At this point the number of changes has grown a bit, and I'm going to feel more comfortable having one more development release (v0.14) before committing the API to stone with a v1. Ideally the transition from v0.14 to v1.0 will not have any changes (basically I'm considering v0.14 to be a release candidate line for v1.0). |
|
Just to bring up a point about semantic versioning. I am aware of requirement 4:
and also your installation recommendation. Making 0.14.0 de facto equal to 1.0.0, however, will break things for people who defined a version like What do you think about releasing it as Just my two cents, I hope you don't mind :) |
|
I never mind feedback (if anything I'd prefer more of it honestly). I probably wasn't clear but I don't expect v0.14.0 to just turn into v1.0.0 (although that would be nice). What I'm concerned about is the possibility that there will need to be a v0.14.1 and a v0.14.2. The number of changes that have gone into this new version here is pretty extreme, and the chances of bugs or even small api changes forcing changes is higher than I was expecting. Part of me was considering v0.14 to be a transitional release (allowing for depreciated methods to reduce coding between versions), but the more I think about it the less that makes sense seeing as there are some BC breaking things already in this release which will force some coding. @andrerom, what's your thought from the perspective of a downstream project with a lot of developer/users? |
|
Glad to hear that. Okay, I see, thanks for your clarification. I definitely see your point and in that case see the need for patch releases. To "solve" the issue with BC changes what about doing several betas for v1.0.0 (-beta1, -beta2, ...). This would agree with semver and with "standard-composer-user-intuition" since their 0.x-code wouldn't automatically updated. Also, it would be really helpful if the docs (or at least changelog/upgrade notes) were already around once you push the code (as whichever release). |
|
Documentation is being updated at tedious/www.stashphp.com#9. I need to do another round on it, and am also considering changing the theme of the documentation site (maybe migrating to jekyll). |
|
From our point we only vary on patch releases, and are well aware you tend to do changes from one minor to the other in the pre 1.0 state. So for us first a 0.14.x, then 1.0.0-beta is fine, just as fine if you jump directly on 1.0.0-beta if you feel the project is ready for that. |
|
As stated, doing 0.14.0 is fine. If you have written ~0.13 as a dependency, you are doing it wrong. The difference between 0.14.0 and 1.0.0-beta is that 0.14.0 will be tested much more by the community. Also, considering semver, isn't all 0.y.z considered as beta versions to 1.0.0? |
# Conflicts: # composer.json
This PR is for building the v1.0.0 line of Stash. It is pulling together all the remaining changes that are needed before launching the stable API.