Hi folks, just wanted to check in here now that we're in December. Unless anyone objects, I'd like to create a 3.10 branch and release a beta on Monday, 8 December. @tfmorris @smierz do you have any issues with this? Do you think any of the in-progress pull requests would significantly change any early testing for 3.10 (and therefore we should wait for them to be merged)?
2 Likes
[...] I'd like to create a
3.10branch and release a beta on Monday, 8 December. @tfmorris @smierz do you have any issues with this? Do you think any of the in-progress pull requests would significantly change any early testing for 3.10 (and therefore we should wait for them to be merged)?
I'll be offline until Monday, but that schedule sounds fine. My previous comment about waiting on the column drag-and-drop feature was before I realized (thanks to Martin's update) that you'd posted a prototype for review (pro tip - if you make a substantive update to a post/comment, also post a separate comment saying "I update the original post / comment / etc." That will trigger the system (forum or Github) to notify people of the update.) I don't have a good feel for how close it is, but I'm open to discussing its inclusion. Martin's UX feedback sounded very similar to my thoughts on the original PR that I think you built off of, but it could be easily fixable.
Tom
2 Likes
no objections from my side
1 Like
Thanks folks! I'm going to create the 3.10 branch and beta release today.
As for drag and drop and the partial history application, I don't want to hold up 3.10 so I think targeting 3.10.1 for either of those features makes sense to me.
The 3.10-beta1 release is out!
I feel like the full release notes would be a better fit for the proper 3.10.0 release, but my plan is to follow the same format as 3.9.
The 3.10-beta1 release is out!
Yay!
I feel like the full release notes would be a better fit for the proper 3.10.0 release, but my plan is to follow the same format as 3.9.
I like that the 3.9 release notes are broken down by categories and lists the issues, which I think are more important than the PRs, but I don't love that the actual 3.9.0 release only includes a pointer to the release notes rather than a copy of the notes themselves.
It's more work to produce user friendly release notes, but I think it's worth the effort. I don't know if any tool was used for 3.9.0 to help, but it seems like the issue # lookup, bug vs feature split, and perhaps some other stuff could be automated. We might also be able to enhance the tagging system with "Major Feature" or some such to help drive the generation / categorization.
I think something is better than nothing though, so I've added the generic automated release notes to the release description. We can refine that as part of the beta process.
Tom
3 Likes
Glad to see it being discussed already but I went here as the release notes seemed to be autogenerated and that’s really hard to get a sense of the changes.
As someone who has helped out writing the release notes in the past and would do so again as I have contributed changes. Was the existing way of writing the notes actually broken in anyway?
Glad to see it being discussed already but I went here as the release notes seemed to be autogenerated and that’s really hard to get a sense of the changes.
As someone who has helped out writing the release notes in the past and would do so again as I have contributed changes. Was the existing way of writing the notes actually broken in anyway?
I replaced "we'll do release notes next time," which I assume was just a time/labor saving shortcut to get the release out, with the autogenerated notes on the assumption that they're better than nothing. They also credit first time contributors which I think is nice to encourage people to keep contributing.
Next steps: filter trivial things, squash "Implemented X" and "Reverted Implemented X" pairs along with "Tried to fix Y," "Tried again to fix Y" series, highlight major features, reword items in a way that makes sense to users as opposed to devs, add links to issue numbers, ...
I've created https://github.com/OpenRefine/OpenRefine/wiki/Changes-for-3.10 but I'm not sure the wiki is going to make for the best collaboration platform, given the formatting differences between it and the release notes' rendering.
Suggestions welcome!
Tom
I've created a draft configuration to control the auto-generated release note process and updated the previously generated release notes with the output from the new configuration. I expect it will require some iteration to get the right configuration and tags to support that configuration (and then the result will still require hand editing, but a lot less).
Feel free to chime in on the issue with opinions as to how things can be improved, whether dependabot updates should be included at all, etc.
Tom
Thanks for the work on the release notes template, Tom! I think it looks great. I wasn't aware that these notes were something we could generate (and in my haste to get the release out I didn't think to generate the notes beforehand).
Regarding the general 3.10.0 release, @Martin has said to me that a video demonstration similar to 3.9.0 would be useful. I'll go through and put together a list of features that would work well in a recorded demonstration, but if there's anything specific folks would like to see please post suggestions.
I hope everyone's having a calm, relaxing end of the year. I just wanted to check in and see if there are any standard practices (either formal project guidelines or an informal individual checklist) from previous releases to help feel that a release is ready to go from beta to general availability. I haven't seen any issues come in related to the beta and I'm not aware of any "show-stopping" bugs that would keep us from releasing 3.10 proper. Has anyone else seen any new issues and/or are aware of a blocker for moving from beta to GA?
Happy New Year! There are no set release criteria. It's traditionally been a judgement call by the release engineer that the product is "ready." This is a combination of sufficient testing and lack of critical bug reports.
I don't have a good feel for how many people have been running the beta and testing it, but I'm suspicious that the lack of discussion indicates a lack of testing -- perhaps not surprising given the holidays.
These are the issues that are in my radar for the final 3.10 release:
7571 - transform dialog box continually resizes
7521 - column mapping dialog overflow (assuming that we leaving the column mapping in, which is probably another discussion that we should have)
6280 - Moving column rename & delete out of the submenu with the rest of the column operations. The more I live with this, the less I like it and I'd be interested in feedback from other beta users as to whether it's really an improvement.
Let's update the 3.10 milestone to reflect the things we want to include.
Tom
Hello and happy new year.
I plan to do a end to end review of all the new feature next week as I prepare the recording of the demo for the 3.10 release. I will report direclty in Github if I have any finding.
1 Like
I've been trying to make progress on testing whether extensions interfere with the basic functionality of OpenRefine. As a part of that, I wanted to share how I've been testing.
To ensure a test failure, I copied the sample extension template and created an extension that removes a chunk of the dropdown menu in the project grid view (the whole repository is here but the only significant line is in this client-side script).
Once I have that extension unzipped into a separate directory, I'll start OpenRefine with that extension installed and enabled. I can then run some of the affected Cypress tests from the root of my local OpenRefine development environment.
Ultimately, these are the two commands I'll run to verify that an extension can cause a Cypress test to fail:
# start OpenRefine with the malicious extension installed
# you will need to change this value to a real path
REFINE_DATA_DIR=/path/to/failing-test-extensions ./refine
# run the Cypress tests for facets
yarn --cwd ./main/tests/cypress run cypress run --spec "cypress/e2e/project/grid/column/facet/facets.cy.js" --browser chrome --headless --quiet --reporter list --env DISABLE_PROJECT_CLEANUP=1,OPENREFINE_URL=http://127.0.0.1:3333
This gives me a bit more confidence that we'll be able to proactively check whether an extension interferes with OpenRefine functionality (though this doesn't let extension developers off the hook for testing that their own functionality isn't compromised by OpenRefine). I've run this with a few extensions and have gotten a few flaky test failures. I'll share a more complete analysis once it's ready.
1 Like
I also haven't heard anything regarding beta testing. I don't have anything else in mind for 3.10. I do think the column mapping dialog should be in; it looks to me like an improvement over the current situation. I don't have much of an opinion on the menu items but my default view is to leave things as they are on the master branch. We can use that as the starting point for the next pass at refining the column menu.
Someone replied to a topic you are Watching.
I don't have much of an opinion on the menu items but my default view is to leave things as they are on the master branch. We can use that as the starting point for the next pass at refining the column menu.
My concern is that we've changed things from 3.9 to 3.10 and I'm not comfortable that the change is an improvement, plus we've haven't had any feedback on it. I'll create a poll to see if we can solicit feedback.
Tom
2 Likes
Poll is live here: https://forum.openrefine.org/t/poll-3-10-testing-new-column-menu/2703
Please vote!
1 Like