Next release

[Lineflyer]

Quite some new PRs arrived recently and also the master branch is already much ahead of the release branch.
I hope, that someone of the team is around next days/weeks to review the open PR?! That would be fabulous and also a good feedback for the PR contributors.

Due to #6905 (Raise of Target SDK required) the PR #7162 (Permission Handling) is the most urgent one to be implemented as it is the precondition to get any new release out and should therefore be the first to be implemented.
As this will be most likely based on master we can IMHO disregard the current release branch state. as we can no longer generate any release from that code state.

I suggest to merge masterto release soon after PR #7162 has been merged to master to have a new base in case we need to release on short term (e.g. website change).

@rsudev @UniQP

[okainov]

I'd really like to have my auth SU changes in (#7170) if possible in one of the next official releases

[rsudev]

@Lineflyer Did you have a chance to look at my screenshots in #5964?
Regarding the open PRs, I do what I can...

[bekuno]

Is there something what other can do to speed up finishing the urgent points for a next release?

[rsudev]

The 'mandatory' thing to do is, to make the target sdk changes ready for prime time. The next step in this area is to get the permission request changes from PR #7126 on top of #7201 and put into shape with a request for storage permission added into the mix.
With #7126 there are IMO two problems: For once, I am not too fond of the idea to completely block c:geo when GPS access is missing (but that could also be dealt with later). Secondly, there are now some activities leaking and I am not sure the flow of initializing the app while requesting permissions is really working/stable enough. And the request for storage permission is missing completely. This is a bit devious, because everything works. But your backups of the database are put into a folder which will be removed on uninstall of the app...
So if anyone can/wants to pursue this further I would be happy. But please announce it as well, so unnecessary double work is avoided.

[Lineflyer]

Now we seem to have some urgency to release due to #7291 which stays reproducible for me (and a lot of people on support).

What shall we do?
I suggest to merge all outstanding design fixes if they are mergeable and of course fix #7291.
Then we are able to release a version which is basically working but still has some design regressions. But this is IMHO better than letting people wait until we fixed all the sdk-regressions.

What do others think?

[moving-bits]

Sounds reasonable, would go for it.

Maybe we can add some text somewhere in the app (about page?) that this is an urgent maintenance fix which still has some known targetsdk26 regressions.

[Lineflyer]

Maybe we can add some text somewhere in the app (about page?) that this is an urgent maintenance fix which still has some known targetsdk26 regressions.

Yes, I was thinking about the same.
Maybe even activate a notification on the main screen with a link to our webpage with some explanations, what happened with the UI. Will think about the best way.

[Lineflyer]

I created a first draft of a possible info:
https://gist.github.com/Lineflyer/b127d42e9624d8a4ecb904341c192d78

[bekuno]

We have PR for the most of the anoying GUI problems. We should also merge them in the urgend release.
Could you then for the open problems make an entry on the documentation (and link to it from the description to the fix, maybe in the release notes)?

[Lineflyer]

Could you then for the open problems make an entry on the documentation (and link to it from the description to the fix, maybe in the release notes)?

I did not fully get, what you try to suggest. Would you like a link of issues still open when releasing, or of the issues already fixed?

[Lineflyer]

Also stated on IRC:

I would suggest to copy master to release now. So we couly more easily differentiate remaining fixes before release from other changes and at the same time could publish an RC version anytime to our beta channel.

And: Does it make any sense to patch the current release branch with the website fix and store it in case we need for any reason to completely fallback to the old target sdk and distrubute the APK manually? Just as an emergency least probable way out...

[bekuno]

I mean a list of known issues.
So users know that we are working on this thinks.

The list of solved issues are in the release notes :-)

[Lineflyer]

@SammysHP If you find time, can you create a new page on our homepage for this purpose. You could take the inital content from my gist posted above. Once it is created I can update it later and maybe also add such a known bugs list as suggested by @bekuno.

We could link it then from c:geo release notes or from a notification or on social networks as well.

[Lineflyer]

IMPORTANT:

Thanks to @rsudev our branches have been updated:

• release has been made equal with master in preparation of a new release
• The old release has been copied to release-old and patched with the fix for the website change. Theoretically we could build a working version close to the currently released version based on that (for emergency).

This means, that now:

• All bugfixes prior and also after the next release should be merged to release instead of master
• New features and unrelated changes should be merged to master

For the our rather new contributors:
You can refer to https://github.com/cgeo/cgeo/wiki/How-to-get-a-bug-fix-into-the-release to get more information.

[Lineflyer]

I will probably try to build and publish a release candidate from release rather soon. We did not yet test if Google Play will accept it and we could get some early feedback from out beta testers.

[Lineflyer]

FYI: RC-version 2019.02.17-RC is live on our beta channel. I will regularly check Google Play for feedback and crash reports and put them onto Github,

[Lineflyer]

FYI:
RC-version 2019.02.18-RC has been tested against #7305 and the fix is working. Published to beta channel.

[SammysHP]

@SammysHP If you find time, can you create a new page on our homepage for this purpose.

@Lineflyer You can create one yourself via GitHub: https://github.com/cgeo/cgeo.github.io/new/master
Just use another page like callfordevelopers.md as a template.

[Lineflyer]

@Lineflyer You can create one yourself via GitHub: https://github.com/cgeo/cgeo.github.io/new/master
Just use another page like callfordevelopers.md as a template.

I thought the same...then I was unsure whether it can be such easy and better ask you :) OK, will do.

[Lineflyer]

New RC pushed to beta channel.

If no new problems arise we should IMHO release the current status for the users to get back into the game on the weekend.

From what we know, there are still the missing spinners and quite some pure optical regressions. Should still be OK as a starting point. We can afterwards push further bugfix releases once a week if we get something done.

Any objection, other proposal or work in progress which could be included before releasing tonight?

[bekuno]

PR #7287 is rebased and ready to include.
It changes compileSdkVersion and the appCompat-Version, so @rsudev should give his ok.

[Lineflyer]

If there is no important functional change in this PR, I would rather suggest to merge it right after release, so we have additional time to test it.

[bekuno]

This solves Issue #7257: " Arrow icon indicating submenu no longer shown "

[Lineflyer]

On the way of releaseing now:

• Check/Insert correct version name as headline in changelog-release.xml
• Build release on CI server
• Perform smoke test with resulting cgeo-release.apk before continuing
• Upload and publish cgeo-release.apk to Google Play
• Tag the release on Github
• Publish the release on Github including upload of cgeo-release.apk to Github
• Publish release on F-Droid
• Rename/Create milestones on Github
• Trigger notification to status.cgeo.org via CI server once the release is available on Google Play
• Post release info to Facebook
• Post release info to G+
• Post release info to Twitter

[Lineflyer]

Puh...Release is out and we should be live with version 2019.02.23 within the next hours.
Thanks to all for participating in this major step forward and bringing us live again!!!

Feel free to merge new things now as needed (bugfixes preferably to release branch of course).

[bekuno]

Fine. :-)
I think the info for open bugs on the regressing info-site should be defined as
https://github.com/cgeo/cgeo/issues?q=is%3Aissue+label%3Asdk26-regression+is%3Aopen

[Lineflyer]

I intentionally included the closed ones, as next days we might have closed issues here which are still contained in the market version.

[SammysHP]

A user reported that the new release is not available via f-droid. @Lineflyer Can you check that please?

[Lomanic]

I was able to upgrade cgeo to 2019.02.23 via f-droid.

[Lineflyer]

I have used our CI to push it to our fdroid repo and the result was green. Did not look into the log though.
I can also doublecheck tonight on my fdroid app.

[Lineflyer]

Version 2019.02.23 is available on F-Droid via our repo.