Closed allendav closed 5 years ago
Legend: ✅ = Include in official notes ☑️ = Omit from official notes ⏳ = In progress
✅ Show admin notice for missing product dimensions instead of requesting rates ✅ Added packing logs to the front-end (with debug enabled) and back-end (order detail screens) ✅ Renaming the "Tariff Code" field in the customs section to "HS Tariff number" and adding a more info link ✅ Once a valid address has been entered as an origin or destination address, the Verify Address button immediately redirects to the next step ✅ Convert the "Edit Address" link in address sugestions to to a proper button ✅ Allow addresses to be entered without verification ✅ Omit extra commas from addresses when a state is not selected ✅ Failed label downloads are now handled gracefully instead of failing shipping label purchases ✅ Shipping methods in the "Rates" step no longer show HTML character codes
✅ Stripe will not attempt to connect if the site is not using HTTPS ✅ Notices on the Stripe settings page are replaced with a helpful and less alarming text ✅ Adding a button for Stripe OAuth connection
✅ Prevent crashes when making proxy requests with a broken Jetpack token
✅ Admin notices are not shown for "unactionable" events
✅ Borderless buttons no longer have a background when hovered
✅ Updated the behavior of the shipping_phone
field in order to prevent conflicts with other plugins
☑️ Remove shipping service status for non-grandfathered sites
☑️ Update calypso dependency to catch the update to npm-run-all
.
☑️ Fix missing button colors with latest Calypso
☑️ Add specificity to root selector to avoid conflicts in Calypsoified wp-admin. (☑️)
...for the readme.txt
file in the plugin
= 1.18.0 =
Section name
* List item 1
* List item 2
We are still waiting for https://github.com/Automattic/woocommerce-services/pull/1513 to be merged.
In the meantime, I think that we should proceed with testing and here is the .zip file for it: woocommerce-services.zip (updated with all PRs)
✅ = Include in official notes
We usually "doctor" the changelogs more, so we provide only information the user can care about. For example, Add specificity to root selector to avoid conflicts in Calypsoified wp-admin.
seems like an internal bugfix, but Ensure compatibility with the WordPress.com eCommerce plan
can be a changelog entry.
This is my shot at the changelog for this release:
= 1.18.0 =
- Add compatibility with WordPress 5.0
- Add compatibility with the WordPress.com eCommerce plan
- When purchasing a shipping label, allow addresses to be entered without verification
- Make the shipping label purchase process more robust, allowing retries when the label image failed to download
- Allow connecting a Stripe account directly from the Stripe settings page
Thoughts? Maybe we could also add a vague "UI improvements to the shipping label address form", since you made several enhancements there.
Note: We need to mark the plugin as compatible with WP 5.0 here.
I copy-pasted the wrong emoji for #1549, it is intentionally in the "Internal Notes" section.
FYI, most entries in the list are already doctored 😆 I have no particular claims for the list, I can make it shorter, although I will still need to add one or two more mentions, especially for the packing log. I see no reason to shorten the list though: On WordPress.org the list appears in the Development tab and for me it makes sense to include details, because then people can immediately know that a specific issue that they were facing has now been addressed. Same for the "View changes" link (or whatever exactly it says in wp-admin/plugins).
In my opinion your list (along with a paragraph or two per item) will be suitable for a woocommerce.com blog post, if we decide to release one (have we ever done it?)
As for the version: https://github.com/Automattic/woocommerce-services/compare/release/1.18.0?expand=1
I copy-pasted the wrong emoji for #1549, it is intentionally in the "Internal Notes" section.
Oh yeah, I didn't notice the emoji, but my point was that it's in the Internal
section but it has user-facing consequences, so it should appear in the changelog (with different wording).
I will still need to add one or two more mentions, especially for the packing log.
Oh, yeah, that's a good one to include! Updated the behavior of the shipping_phone field in order to prevent conflicts with other plugins
is a good one to include too, sorry I skipped it on my first pass.
I see no reason to shorten the list though: On WordPress.org the list appears in the Development tab and for me it makes sense to include details, because then people can immediately know that a specific issue that they were facing has now been addressed.
The shorter it is, the better chance there is that people will actually read it. Users don't care if this release has an extra "more info" tooltip in the HS Tariff Code
field, or if a link is now a button, but they may care if something that wasn't possible (or was broken) now it's possible (connect the Stripe account, allow unvalidated address), or compatibility issues (Calypsoify, WP 5.0) have been fixed.
In my opinion your list (along with a paragraph or two per item) will be suitable for a woocommerce.com blog post, if we decide to release one (have we ever done it?)
I think we've only done it when a major feature has been introduced (first plugin release, shipping labels, international shipping labels, etc). The question you have to ask is "Will this update make someone consider installing this plugin?", and I think in this case the answer is "no". People that have the plugin installed will already see the update notification, so no need to "advertise" to them.
The shorter it is, the better chance there is that people will actually read it. Users don't care if this release has an extra "more info" tooltip in the HS Tariff Code field, or if a link is now a button, but they may care if something that wasn't possible (or was broken) now it's possible (connect the Stripe account, allow unvalidated address), or compatibility issues (Calypsoify, WP 5.0) have been fixed.
Alright, I will doctor it and will probably follow your list/example.
I think we've only done it when a major feature has been introduced (first plugin release, shipping labels, international shipping labels, etc). The question you have to ask is "Will this update make someone consider installing this plugin?", and I think in this case the answer is "no". People that have the plugin installed will already see the update notification, so no need to "advertise" to them.
I agree.
Do you like it like this?
Tests well on WP 5 for me. I also tested: