What are the changes in releases?

advocatux

@wlbi I ask this same question periodically, but it seems it's very difficult to have some kind of changelog.

Last time I asked in the SG (April, 14th), @Flohack answered me

Its also very hard to do this without a very very strict checkin / pull / branch strategy, that you can only enforce with putting up a lot of rules for devs.

On the other hand, you can dig in https://ci.ubports.com/ and https://github.com/ubports to see the latest commits & changes.

WLBI

@advocatux
Well, when Canonical was still the developer, you can see that in your device.
If you do the Update, then you can see a list of all installed Updates.
Below each update is very light grey the version umber.
If you tap on that in the Canonical version, it's like a pull down menu and you was able to see a small change log.
For me it still looks almost the same, like first time, when I installed 16.04, when Canonical was still the developer. So I have no idea, what changed and what's new.
It should not a big changelog, but alt least some small keywords, in 2 or 3 lines.

UniSuperBox

Changelogs are one of the most requested features, but I don't think that they would be useful if they existed. For devel builds:

The builds are done daily with no human interaction
The volume of changes is so low between releases that it doesn't make any sense for the time spent
No one wants to keep track of every single change to write them down

If you would like to see the changes between each build, we're normally working toward one of the closest milestones, so check the project board for items that have recently been closed and need testing.

hummlbach

Perhaps someone (would be okay if it was me ;)) could (semi-automatically) collect all commits containing the keywords that github uses to automatically close issues? Might not work 100%, is not very comfortable for the readers (because you perhaps would have to look up the issues referred to, to understand what the change was about), but its better than nothing and in principle you then have your changelog. @UniSuperBox would that be imaginable? I would try to do that every to weeks to the q&as...

UniSuperBox

@hummlbach, Anything is worth a try at least once! Give it a shot, let's see how it goes.

flohack

@wlbi Additionally to what the others said: 16.04 is a more or less boring release, since we are just trying to get it to work to be on the safe side of supported LTS. We did not really do many new features. One of them however will be basic printing support, so you might be able to print PDFs soon

WLBI

@flohack
How would it be, if it is not a super technical changelog, and just some short things. For example:
Bug battery drain fixed
HDMI output working
Added keyboard layouts GR, FR

If I am searching in Google, I can not find a changelog for Ubports.
I really have no idea, what's going on in the different updates.

flohack

Hmm if that helps you can do the following:

Go to our milestones in Github https://github.com/ubports/ubuntu-touch/milestones?state=closed
Click on a closed milestone
Click on the closed word in the header to switch the view to see all closed issues

This is roughly what was changed on previous releases, and for the open milestone 16.04 you will see whats upcoming. Though for 16.04 we had to fix so many small things that not all of them were triaged correctly before being fixed.

flohack

Specifically, https://github.com/ubports/ubuntu-touch/milestone/7 tracks all regression bugs that we are aware of, and that should be fixed before 16.04 can be released.

hummlbach

Since auto close is a bit tricky to use and it's mostly not used @ubports my actual plan to use the commits containing auto close keywords did not work. Instead I'm now using the issues themselves (via the REST-API see https://developer.github.com/v3/) to create some kind of change log. Unfortunately this approach has at least two problems:

pull-requests are also listed as issues, so that you get duplicates for those issues fixed by pull-requests (as it is the case for issues in the core apps).
Issues closed because they are invalid are also listed, which can be very confusing...
Already closed issues could be changed after they were closed, causing them to be listed, although they were fixed long before.
Github services is deprecated since 2018-04-25 [meeh].

I'm putting the far from perfect "change log" for the past three weeks from Q&A26 to Q&A27, as well as the hackish bash-script used to create it on paste bin. If you want to use it you'll need patience - it takes some time to traverse over 300 repositories, and you have to replace user:password with your github credentials at the beginning of the script - authentication is needed, because otherwise you would hit the rate limit. The script is started with two parameters: the first being the user or organization for which you want so see the "change log", for example ubports and the second being the start date for the change log in the format YYYY-MM-DD. So for example:
github-changelog-by-closed-issues.sh ubports 2018-04-14 > ubports_changelog_qna27.txt
Perhaps anyone has some ideas, on how to improve it... I think we should at least include the URL to the issue or/and perhaps also the description, not only the title (but then it will get longish) and use python instead of bash...

ubports_changelog_qna27.txt
github-changelog-by-closed-issues.sh

flohack

As first measure I would filter out Weblate. Translations are continously updated, and we do not need to know this in the changelog IMHO

hummlbach

Okay. Rewrote it in python. Its called the same way as before. Issues containing "Weblate" in the title are filtered out. Now really only the issues that have been closed since the date given should show up. Changelog since 1st of may can be found here: https://paste.ubuntu.com/p/QxMp9QSvbP/. I did only one test run, so please find bugs here: https://paste.ubuntu.com/p/692fKNSMsw/