Cgeo: Next feature release

Created on 24 Oct 2017  路  59Comments  路  Source: cgeo/cgeo

Its once again a big gap between release and master already, which makes me think about finding a new cut to do a feature release. The major new feature on master seems to be the waypoint calculator, which basically works and some issues are known and about to be adressed. Additionally we have some other features like OC-picture logs.

While using the nightlies I have the slight impression that we got some unstability, which I was not able to reproduce or track down right now. It is just, that c:geo more often crashes randomly.
As I have only limited time to test at the moment I would therefore suggest to use our beta program to let users test based on current master, Therefore we should IMHO merge master to release asap.

We will not have a version which I would consider ready to be released right away, but it allows us to

  • Freeze current feature state
  • Release a beta version
  • Fix found issues on release

I have seen that some PRs are still open (mainly dealing with the calculator), therefore my question would be if we should wait until these are finished and merged or rather align the branches now and merge the PRs to release once they are ready?

Waiting for your feedback.

Feedback required

Most helpful comment

IMHO we can release a version from release branch next days:

  • Beta feedback did not show negative results/support mails
  • Crash reports on Play do not show anything new/unusual
  • Smoke testing on my devices performed normal

Any objections?

All 59 comments

From my point of view I would like to see the current PRs for the calculator be merged first. They address some possible crashes.

I also think #6715 should be fixed before merging to release. Because this would cause a DB change (remove a column).

Having tested the WP calculator a lot I agree with @pstorch. Without the current fixes being merged c:geo can be crashed easily.
Same for #6715: I guess users would lose the calculator specific notes after #6715 is done which is probably only acceptable for nightly users.
Without #6715 there are three different waypoint notes with other issues, e.g. this information is not duplicated.

Its without doubt, that these fixes shall come in before release or publishing a beta.
My question regarding the PRs was more if they should be finalized on master first and then copy to release or copy to release immediately and fix on release.
From @pstorch answer I learned it should be done on master and only then copy to release.

Then I suggest to put no more huge untested changes (other new features) on master while it has not yet been copied to release.

Just realized that I was wrong about #6715: the calculator note is not a separate column. It's just in the calc_state column together with the variables. But nevertheless I think this should be fixed, because it either needs a more or less complicated migration or causes data loss.

From my point of view we can start a new feature release branch.

Just a sec, I'll download the last translations.

From my point of view we can start a new feature release branch

As you have probably best insights into the calculator progress, you are the best to judge.
So just go ahead once @rsudev downloaded translations.

Due to the huge gap between 藡master藡 and 藡release藡 the question is, if we want to save the state of 藡release藡 into another branch as a backup in case of "emergencies"?

Due to the huge gap between 藡master藡 and 藡release藡 the question is, if we want to save the state of 藡release藡 into another branch as a backup in case of "emergencies"?

That's what tags are for. We can always checkout a market release tag and branch off from it for emergency fixes. It's not needed in advance.

As we have a tag on that, it is not necessary. We can always create a new branch on that in an instant.
BTW, latest translations merged.

@rsudev :smile:

Ok, master merged to release.

Will check and try to build a beta version later today or tomorrow.

After first little confusion I merged changelogs according to the description in https://github.com/cgeo/cgeo/wiki/Prepare-a-release

@Lineflyer thanks, I forgot. Sorry.

You could complete the process by merging up to master again. So changelog_master will be emptied on master.

done

Mmh..it seems the WP Calc does not work on 2017.11.01-RC I built from release branch. See #6816

After fix of #6816 was done I did a quick smoke test (not much time to test deeper) and think we should give it a try in our beta channel.
Will publish it tonight or tomorrow.

OK, beta version 2017.11.01-RC2 is live.
I will collect feedback from Google Play Console and support mail next days as time permits.

@pstorch
IMHO we should stopp fixing random findings on release as done with the commits today.
I could imagine, that e.g. "move/copy from history" might have some unexpected side effects". I would like to focus on testing the new features and only fixing issues related to those on release. Otherwise the possible testing range gets even wider. What do you think?

BTW: I did a bike power trail today and used c::geo RC-version for all of them incl. the calculator for various multi, mystery and letterboxes on the way.
Worked perfect...we only seem to have a problem when returning to the app from standby...but no clear view on the preconditions (random crash when returning to c:geo...mostly when returning to the map).

And I found some examples, where I would like to know whether the calc can be used for them (will post seperately).

@Lineflyer sure, that was a lot today. Don't plan to do anything else now. Waiting now for beta feedback.
There is only the discussion left if we should include #6815 into the release or not.

I posted a comment on #6815. I must admit that I did not follow the long threads of trailing/leading zeros close enough.
Maybe it would be a good idea to open up a new issue explaining the current implementation (depending on coordinate format used...if any dependence) and let us think about a meaningful way. Or is there an issue already?

FYI:
AFter the discussion in #6827 I just uploaded another beta version 2017.11.07-RC from release branch as of commit 826026b8812de38cab4a128f4edc28a96402b20b

Is the fix for #6716 the only thing which is open for this release?

Is the fix for #6716 the only thing which is open for this release?

I think so and we have to look what happens to #6827

@S-Bartfast has a point in #6716 of having the fix for #6835 included in the release as it might help with the discussion about the leading/trailing zeros.
What do you think?

While I agree that it is a cool feature because you might be able to copy a formula from the listing directly into the calculator, I do not see how this will help with the disagreement about leading or trailing zeros for DegDec or even Plain.

As some of you might have seen I posted a calculator screenshot together with promotion of the beta version onto our Facebook page.
Quite some of the feedback goes into the direction, that the ability of C&P for formulas (which is reflected in #6835) is seen as a key feature, which makes the calc usable.

This implicitly also comes back to the question of leading/trailing zeros as discussed in #6716.

So I suggest to decide upon #6716 first (also thinking about what is prefered with respect to #6835), implement this on release and then decide in this thread whether we can/want to include #6835 before releasing (i.e. also on release) or not.

Nice to hear.

I just thought I make a quick mention that #6802 (Coordinate Parser Needs Work) will likely be of more concern once #6835 (Allow use of Brackets for the calculator while in 'Plain' format) is released. At present the parser accepts all kinds of rubbish and with the release of #6802 this will only become more apparent.

I'm not suggesting we should hold up the release until #6835 is addressed, just pointing out that the parser is in fact pretty flaky and I suspect the only reason it hasn't been brought to anyone's attention is that it is rarely used but with the implementation of #6802 I dare say the parser's shortcomings will be come much more apparent.

Reading the comments in the above mentioned Facebook page, I see a high demand for just copying and pasting formulas incl. brackets into the calculator.
So maybe we should include #6835 into this release. I also think about having the Plain format as default in the calculator to make it clear that the user can paste in something. Some users missed this possibility.

If it would be merged to master at least I would give it a try immediately.

After having tried the PR for #6835 I would like to see this feature in the release. Plus applying the leading zero mode for "Plain" only (in addition to MinDec and similar formats).
It worked so well with various caches I tried that I absolutely agree with @pstorch that users will prefer this over the button approach.

Plus applying the leading zero mode for "Plain" only.

What????
PLAIN ONLY!!!!

Surely that's not what you mean.

Of course not.
We have two formats where there is no common agreement: Plain and DegDec.
To move forward I would implement at least for Plain also leading zeros as it is already for MinDec and friends and leave DegDec out of the discussion.
I've also edited the comment above,

Of course not.

Phew, I thought for a moment you were about to go 'rogue' there :p

To move forward I would implement at least for Plain also leading zeros as it is already for MinDec and friends and leave DegDec out of the discussion.

Yup, I'm onboard with that.
(Damn you DegDec, you are the cause of so much misery!)

So maybe we should include #6835 into this release. I also think about having the Plain format as default in the calculator to make it clear that the user can paste in something. Some users missed this possibility.

I agree to that proposal.

Furthermore we should implement the "all leading zero" solution for the calculator.
The waypoint input itself I suggest to leave untouched right now (for next release).

Furthermore we should implement the "all leading zero" solution for the calculator.

Oh, interesting. We finally talked you round did we @Lineflyer.
Welcome to the club 馃榿

So can someone summarize a list of issues to be completed first before release?
I think it could be:

  • [x] #6845
  • [x] #6835
  • [x] #6716
  • [x] #6843

Anything else?

I think #6843, too.

And do we have a final agreement for #6716 (leading zeros for all formats)?

I think #6843, too.

Yes, added it.

And do we have a final agreement for #6716 (leading zeros for all formats)?

Well, at least I got convinced in the meantime that leading zeros are OK for all formats (refer to my posting above).
I would get the coordinate input dialogue untouched, but apply leading zeros to the calculator for all formats.
So AFAICS we should have a majority now for leading zeros...so lets just do it.

...so lets just do it.

:+1:

How about #6842? It makes the interpretations of the calculator more transparent.

One ticked off, one to go :sunglasses:

@Matze2 I couldn't test #6842 yet. I don't know if it is necessary for the current release. Useful probably. @Lineflyer: what do you think?

6842 sounds indeed useful. IMHO we should include it and then make a final testing round.

Ok, let's change the target for related PR #6848 to release.

@Lineflyer ok, #6842 and #6835 are in the release now and ready to be tested

Nice...will check it.

Current release branch was smoke tested and a new RC-version published to our beta users (2017.11.26-RC).
I also triggered a new nightly build (which is still running) in case someone is interested in checking the latest state.

Yes I will use the nightly as soon as it is available.
Thank you everybody for making that possible.

Does everybody consider the release branch ready for being released?
If so, I would closely watch the beta channel next days, do some tests myself and maybe next week we can decide to release it.

@S-Bartfast
The included help function for the calculator is not ready yet. I don't see it as mandatory for the initial release of the calculator.
But I would like to ask you for a favor in case you find some spare time:
You did a really nice tutorial video presenting the calculator some months ago. Would it be possible for you to create another video with the current state and its features. That would be a great thing to offer our users if they ask us regarding usage of the calculator. I could offer to do subtitles in german (although I have no idea how to provide them to you for the video on Youtube..mmh).

Yeah, I can do that.

BTW: Regarding subtitles you can enable community contribution on Youtube: https://www.youtube.com/watch?v=jiEybiElXgk

I tested the plain mode with brackets and prepared all stages of GC768Y3 with the formulas provided in the waypoints. Apart from one place which contained blanks around the decimal point everything worked fine.

The fact that I now have 18 useless waypoint coordinates after the preparation is a different story/issue. :smirk:

I somehow experienced the waypoint duplications, too. But wasn't sure if I did something wrong.
We should open an issue for that.

IMHO we can release a version from release branch next days:

  • Beta feedback did not show negative results/support mails
  • Crash reports on Play do not show anything new/unusual
  • Smoke testing on my devices performed normal

Any objections?

As I have less time next days, lets release now.
I will go for it now.

Checklist:

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

Release process stopped due to #6865

After fixes have been integrated for the recent issue we decided to continue the release process.

We are done!

This time it was a long way (as you can see by the length of this thread). Thanks to all involved and special thanks to @S-Bartfast for the intense work on implementing a useful calculator!

Was this page helpful?
0 / 5 - 0 ratings