PhpSpreadsheet
PhpSpreadsheet copied to clipboard
PHPOffice
Array formulae in the Calculation Engine
This is:
- [ ] a bugfix
- [ ] a new feature
- [ ] refactoring
- [ ] additional unit tests
Checklist:
- [ ] Changes are covered by unit tests
- [ ] Changes are covered by existing unit tests
- [ ] New unit tests have been added
- [ ] Code style is respected
- [ ] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
- [ ] CHANGELOG.md contains a short summary of the change
- [ ] Documentation is updated as necessary
Why this change is needed?
Creation of the version 2.0 development branch.
All changes merged into master should also be merged here to keep it up-to-date with bugfixes and any new features introduced in master
It should not be merged to master. When the time is right, we'll have 1.x and 2.x branches, this forming the basis of the 2.x branch
@MarkBaker how would this work? Let's say I'm ready to merge #2775, which corrects two typos in a single module. Do I need to do something to merge it to 2.0 before I merge master to it? After? After I merge it to master?
It's going to make things fairly complicated for a while; and I'll just try to keep it up-to-date myself initially.
master is still the master branch, and all feature and bugfix branches should still be branched off master and merged back to master when they're accepted.
Merges to this 2.0-development branch should always be from master itself, not from the bugfix/feature branches that are merged to master; that way, we retain the git history as much as possible, and won't lose any changes applied to master.
It doesn't need to be every individual merge to master, but fairly regularly we'll need to merge master into this 2.0-development branch so that those bugfixes and new features are in both master and 2.0-development. Large merges into master should generally then be merged from master to 2.0-development immediately, smaller changes (typo fixes, etc are less important) the merge is from master to 2.0-development (rather than from the feature/bugfix branch), so several changes to master will all be picked up with the next merge to 2.0-development.
The main factor is the risk of a merge conflict. If this merging to 2.0-development is done regularly, the chances of a merge conflict are reduced, and they're generally easier to resolve when they do occur.
At the same time, any changes that cause a bc-break should only be against 2.0-development, rather than against master.
I'd expect that we'll have at least one more 1.x release before we're ready enough to think about a 2.0 release, so it will be a few months.... perhaps around the end of June/earl July. Once we're approaching the stage where 2.0-development is close to a 2.0 release, I'll rename master as 1.x and rename 2.0-development as 2.x and we'll have a transition period where we have to merge features and bugfixes to both 1.x and 2.x (and there's a higher risk of merge conflicts). It will become a case of monitoring the take-up of 2.0 on packagist, but we'll reach a point where we can put 1.x into maintenance mode (only bugfixes, and not new features). Hopefully, most users will transition to 2.0 fairly quickly, so that period shouldn't be too long.
@MarkBaker I have a security-related question that I would like to discuss with you privately. I sent an email to an address I had used to communicate with you about another security-related issue in March, but a new message to that address bounced yesterday. How can we discuss it?
Screaming into the void
I really do not like the way the tests have been rewritten; with an abstract base method being used to handle all the test calls and assertions; it hides everything from the actual unit test code.
It was a nightmare to merge so many files manually; and it's created a new nightmare that will take hours and hours of work to fix
I'm sure that must have been my doing, so please accept my apologies. Responding to a user issue, I found there was a huge number of deprecations that had previously been unreported because of lower/uppercase considerations. I got rid of most of them (now and for future module moves) by changing the tests to run in spreadsheet context rather than by direct calls, and, since the logic was basically the same for everything (populate the sheet then calculate the result), it simplified matters a lot to use a common routine that all the tests called. I am sorry that this caused problems for you which I did not anticipate. Is there anything I can do to help?
@MarkBaker it seems this branch went stale. Are you still planning to work on it in the future ? or should we close the PR ?
There's some major changes here for handling array formulae in the Calculation Engine. Unfortunately, too many changes to master made it almost impossible to keep it up-to-date. That feature did include a bc break for anybody using custom read filters, hence the v2.0 naming.
I do want to implement those array formulae changes at some point, I'll need to extract them from the branch and re-implement against a new branch. Hopefully, I'll find more time to work on it this year after the craziness of the last year. So I'd prefer to keep the branch for the moment. Once I'm employed again, I'll take another look at which commits I can take across to a new version 2 branch
Fair enough. As a head up I'd like to remind you of https://github.com/PHPOffice/PhpSpreadsheet/issues/3788#issuecomment-1807345002 where I mention that I planned to release a v2 because of added native typing pretty much everywhere.
Is that OK with you ? Would you have any breaking changes you want to add before releasing (hopefully in a few days) ?
Fair enough. As a head up I'd like to remind you of #3788 (comment) where I mention that I planned to release a v2 because of added native typing pretty much everywhere.
Is that OK with you ? Would you have any breaking changes you want to add before releasing (hopefully in a few days) ?
I'd go ahead with the deployment of v2.0. I have some new documentation to add before then (I'll try to do those this week), but I won't be able to extract my array formulae changes in the next few days (too much job hunting and preparing for my Netherlands naturalisation exams that take priority) so that will wait for a v3.0, perhaps in a few weeks time.
@MarkBaker, @oleibman, I just released https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/2.0.0 :tada: