| Daniel Speicher |
Do we still have critical Tickets? And do we plan to create a BETA or something? |
| jurgenhaas |
Looks like there is a lot before tagging an alpha or even beta. |
| jurgenhaas |
A11y, gateways and debugging improvements are the 3 main topics. Most of them haven't even been started. |
| rkoller |
and most of the a11y tickets were created upstream. i have to revisit them on the weekend and get up to speed. after the write up my eye issues flared up again. and when things got better to many things at once. so i havent had time to check. |
| Daniel Speicher |
Do we really need all of them? It is quite usual, that not all features are added to the very next release. |
| jurgenhaas |
That's correct, but those are the ones that we announced to be part of the next release. So, unless there is an important reason, we may want to stick to the plan. |
| jurgenhaas |
Also, the Form API improvements fall under the umbrella of A11y in this context. |
| Daniel Speicher |
I think, we should be more careful in announcing too many big features. A lot of tickets are done, but cannot be shipped. And in my opinion we are not bound sticking to plans, since they change anyways. I understand that we want to keep our promises. |
| jurgenhaas |
Hmm, are you sure? I don't think we have a single new feature yet. What we've done is fixing a few bugs and they get back ported into version 1.1 where they get released. |
| Daniel Speicher |
The cache stuff? |
| jurgenhaas |
That's true, forgot about that one. But that's kind off tiny, isn't it? |
| Daniel Speicher |
It is not very big, your are right. “Provide value fast”. That was my intension here. I think, we made good experience in our company in shipping software very often. If the customer does not like this, he is able to control via composer. We should also try this here. Of course, at least one new feature should be done. For 1.2, I also think we should start/finish one of the three, you mentioned above. |
| jurgenhaas |
Agreed, small improvements and fast shipping is a well working method. From the features we currently have on the roadmap for 1.2, gateways and logging improvements are the 2 recognizable new features and I think, those should go into 1.2. The a11y components are either not ECA, i.e. what @rkoller is working on. And the Form API improvements are "under the hood" improvements, that won't have any impact until the modellers will make use of them. Therefore, they should also go into the next release because otherwise modellers won't be able to start working on those improvements. |
| jurgenhaas |
My impression was, that we had been a bit too fast with ECA development and should give the team and the community a bit of a rest, before another bunch of new stuff gets into a release. We talked about waiting until around summer before 1.2 was expected. |
| Daniel Speicher |
Agree |
| rkoller |
one question. when bpmn is updated. is it “just” replacing an older version of the bpmn js file with a newer or are there additional steps. i ask because i wanted to know how tricky it would be to run “dev versions” or patch versions of bpmn in drupal? cuz being able to provide feedback on changes in the different issues upstream i would have to actually test it on my own in the browser. but i am not sure how complicated it would be to replace one bpmn version with another in a dev install? |
| jurgenhaas |
There are quite a few steps: updating all NPM dependencies and then running an NPM script which builds the webpack application, which is a bunch of JS files. |
| jurgenhaas |
But this can be done for testing, it's no rocket-science |
| rkoller |
but when everything is built it is easy to replace the built assets that are currently in the bpmn module with the new ones? it is a simple replace. that replace was the part i was uncertain and worried about. that each new version would require a certain amount of adjustment within the bpmn module in drupal? (edited) |
| jurgenhaas |
The build process will write the assets into the correct destination already. You only need to flush your Drupal cache and reload the page, that's all |
| rkoller |
ohhhh okaaaay. that sounds convenient |
| rkoller |
and the webpack file you are using for building could be found in the build directory? is it that one? |
| jurgenhaas |
Yes. What you can do is in a regular Drupal installation, cd into the BPMN build directory and call 2 commands:npm up
npm run all(edited) |
| jurgenhaas |
That will build the webpack application in the webpack directory. The module's library file picks the assets from that directory. |
| rkoller |
ah excellent. thanks! will check if there is something similar to the patch or merge request workflow for github so i am able to add no merged work on changes to such a build. will looks that up over the weekend or ask over there in one of the issues. |
| mxh |
I currently don't know the meaning of ECA's version scheme usage. Maybe we can briefly clarify that here. |
| mxh |
Until now I thought we basically orientate on Drupal core's version scheme:The Drupal (core) version numbering scheme is simple enough: Major.Minor.Patch - for example 8.8.5. The major version number indicates compatibility, the minor version number indicates new significant features and the patch number indicates bug fixes and minor enhancements.However it seems that it doesn't apply for ECA's version scheme. |
| jurgenhaas |
That's what we intend to reflect in ECA as well :+1::skin-tone-4: - if the background of your question is the PHP 8.1 dependency, then we have discussed that in the last meeting and came to the conclusion, that this was the right move for 1.2, see https://drupal.slack.com/archives/C0287U62CSG/p1675267338600239 |
| mxh |
Yes, that's the issue that's raising question marks for the version scheme. First thing is that I somehow missed that "Raise minimum requirement to PHP 8.1" means "Refactor all code to use all new PHP features". Second thing is that the applied refactor is now breaking compatibility with implementations that extend from ECA classes which are not marked as internal. Such BC change would normally go into a major version update, or am I wrong about this? |
| jurgenhaas |
Well, this is under our governance and we are free to make those decisions. Going up to PHP 8.1 without adjusting the code didn't seem to make sense, why would one want to do that? Other implementations of course need to adjust as well, but there is no hurry. It still feels like months to come before 1.2 will be tagged. |
| mxh |
Looking into the linked discussion and into the issue description, I don't see any mentioning about refactoring existing implementations. My understanding of the linked discussion is, that the minimum required version would be raised by definition (i.e. in the composer.json and/or info.yml file) so that new feature additions can be implemented using the new features of 8.1. But I don't see the mentioning of changing the existing API. |
| mxh |
Maybe at this time, most implementations are resided within modules of our own (however by increasing usage numbers, also others will have their own extensions too). Still this means additional work by adjusting affected components. I'm questioning the reason of such additional work, as long as we're not upgrading from one major version to another. |
| mxh |
Plus the refactoring brings a risk of breaking existing process configurations, although the existing tests might still be green. |
| jurgenhaas |
I see your points, but still the suggestion for raising the PHP version was just for that one point, to raise the code quality. We had discussed this a few times, the code analysis tools have had complaints all over the place, and the PHP 8.1 improvements allowed us to identify and fix them. |
| jurgenhaas |
Our code base is fairly large and for maintenance, it's important to keep that under control with such analysis tools. It felt like it was still the right time to do that and as we are early in the 1.2 process, there is enough heads up for other developers to catch up. |
| jurgenhaas |
However, instead of calling it 1.2.x we could change path and go for 2.0.x - but I don't want to revert the code improvements. |
| jurgenhaas |
That would then be for Drupal 10 only, which seems to be helpful too. |
Comments
Comment #6
jurgenhaas