-
-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changelog for v3.3.1 #830
Changelog for v3.3.1 #830
Conversation
@cibersheep Would you mind checking the descriptions re. Ubuntu Touch? |
CHANGELOG.md
Outdated
|
||
* NOTICE: This is a bugfix release to fix critical errors with the Ubuntu Touch app. For main changelog, see v3.3.0 below. | ||
* FIX: Improve packaging for the Ubuntu Touch app | ||
* FIX: Provide platform-compliant ID for Ubuntu Touch app |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the id of the UT app has been changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not the id but the hook name. That affects where several files are stored (.desktop, manifest and appamor). Also, logs will show kiwix_[...]
instead of ubports_small_webapp
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose it means the user will loose their settings (which are stored either in cookies or in the LocalStorage of the underlying browser).
I don't think it's a big issue, but it would be worth mentioning it in the changelog.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, how can I word it? -
- Provide a platform-compliant hook name for the Ubuntu Touch app (note that settings may be lost when upgrading to this version)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds great
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, will commit wording, but we should wait till we have a sure date (12th Feb) to add to this PR before merging, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add mention of mitigating against log4js exploit? It's more testing-related than app-related. Don't want to scare people! On the other hand might be good to show we're up to date...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
npm is only used for running tests for now, so log4js does not end up in the packages we deploy.
So I would not mention it in the changelog file.
OK to wait for the date, but it's not an issue if it's "wrong" of one or two days, IMHO
Second thought, I dont think we should "merge" 3.3.0 and 3.3.1 milestones on github. We should be clear on what is included in each version. I can handle that if you want |
The description of the app will be visible when published on the OpenStore Icon and splash (looks paler because is difficult to screenshot it, too quick XD) on real device |
@cibersheep : I suppose @Jaifroid meant that he wanted you to check the description of changes he wrote in this PR |
I did it: created milestone 3.3.1 https://github.com/kiwix/kiwix-js/milestone/28 , and moved the corresponding issues in it (hope I did not forget any) |
OK, great! That makes sense. Just for the record, my reasoning was that our milestones are large (major) categories that only have two digits, whereas we give releases numbered with three digits. But I agree it is best to have a milestone per release, especially as this turned out to have a bit more in it than I expected. |
Answering properly now (^_^) it looks great! |
@cibersheep Thank you very much for your help! |
Co-authored-by: Mossroy <[email protected]>
@mossroy I'm merging this now, so you're free to create the tag at any point tomorrow or Sunday. I presume we're only releasing this for Ubuntu Touch, plus the PWA that should automatically update if all goes well, nothing else. I think we did all the necessary testing last week. The app code hasn't changed other than the correcting of the race condition preventing load of decompressors. But let me know if it needs more manual testing. |
Please check if the descriptions are accurate for the changes regarding the Ubuntu Touch app.
I include 3.3.1 under the 3.3 milestone, so if people check the closed milestones, they will see all the commits for 3.3.0 and 3.3.1. I think this makes more sense than creating a specific milestone for 3.3.1, given that it is a minor version.