Release plans for app store/roadmap etc

[kwatkins]

This is moving to more of an open source community project, which is great, now how should we/or what point release it on the app store? And,

• Possible rename of the app?
• Update description to show contributors etc
• Formalize Issue tracking (bug/feature/design tags)
• Code development, feature branches, development, version tags, release, etc

Or I can simply drop the latest/master on the app store when we think it's ready. Of course it could use automated testing to pass, but eh, I'm happy to be the monkey test runner riding a OneWheel for the cause :)

[ebabel]

Renaming the app is possible, and easy (if that was your question). Changing the package identifier is not possible.

[wmaciel]

• I always wondered why the app was named the way it is. I don't have a problem with it though.
• I would not oppose to a description showing contributors :)
• We could adopt some issue tracking conventions. I'm sure there's some "open" convention we could use.
• I would be fine with feature and release branches. Maybe the issues could have a branch and when closing the issue we just merge to master.

To be honest, I think it is working ok for now.

Actually, I think some testing would go a loong way.

[ebabel]

If you do add a contributors section, please don't include my email

[wmaciel]

That's a good point.
I meant maybe a github link, or just a name

[ebabel]

It's like Pwn, right? Which is funny for geeks but maybe everyone doesn't know. I like the name but also down for whatever :)

[kwatkins]

pwned - https://publicdbhost.dmca.gripe/ - with an email, able to crack about most anyones password from the leaked data breaches, 2factor to the rescue...

Sounds like the app name is good, I just brought that up in case anyone had opinions on it :)

"I would be fine with feature and release branches. Maybe the issues could have a branch and when closing the issue we just merge to master."

I'm good with that, feature and release branches are easy enough.

"Actually, I think some testing would go a loong way."
I totally miffed on doing unit tests, partly because testing BLE features require the actual board. For UI and other components the expresso unit tests etc are there. I used it to test the battery grid. Definitely open to further suggestions on what testing we should do/what I can help with prior to merging to master.

I'll update the description with credits :) Thanks all!

[ebabel]

I've been liking MVP lately and sticking to strictly JUnit tests, no android, no espresso.

[ebabel]

@kwatkins I'm down to release to the app store as often and soon as possible! The store version still doesn't have plus support, right? That's HUGE!

[wmaciel]

I agree, I think that constant updates shows that the project is not dead and keeps people interested in whats coming up next.

[wmaciel]

Of course, that will require a bit more scrutiny before merging into master.

[wmaciel]

The first version of my OW hud video is out and it got quite a bit of buzz about which app I used to get the logs.

A lot of interest in using it on the OW+

Do you guys think we could tidy up and make a release focusing on getting OW+ support out?

I think this could generate quite the traffic to the app, and we could get some nice feedback.

[ebabel]

Sounds good to me. What's on the list?

[kwatkins]

@ebabel @wmaciel @twyatt dropped the current master as an open beta release
https://play.google.com/apps/testing/net.kwatts.powtools
I'll also update the main page for this link.

[ebabel]

Awesome Kevin!

Was this a33afdc? If so we should tag it.

[kwatkins]

Yep - tagged (v3.0-beta) and set as a release in Github.

@ebabel looking into sharing the project on google developer console w/ya, not sure if it can be done but should be a common enough scenario/use case.

[audkar]

in response to #82 (comment)

Short of putting firebase and having logs show up there, are there tools/best practices for this for open source projects? If not, we can add firebase

For OSS same tracking tools are used.
‼️ However need to keep in mind GDPR. If any information will be logged and sent automatically to analytics/crashlytics services which can tie data with user then we need to show consent to user. And that includes user location, user device identification id, MAC, etc.

---

we need a workflow going, where we tag a dev release, gets pushed to google play, we test it internally, looks good, pop it to beta - users love it, we see the logs and that looks good - push to production...

This is not difficult but mostly can be done only by project owner.
Pipeline steps can be like this:

• [manual] Tag commit in Github (a.k.a create release)
• [auto] Circle CI special job gets triggered (reacts only to tags)
• [auto] Pre-release tasks run (tests, lint, static code analysis, etc)
• [auto] Publish task executed. This Play store upload plugin can be used to upload artifact to PlayStores' internal track.
• [manual] Promote release from internal to beta track
• [manual] Promote release from beta to public track

‼️ Don't commit any sensitive data to Github (like google-services.json or any publish keys).

If I can help in any way just ask.

[kwatkins]

@audkar Yep, I know GDPR all too well :) It will be interesting to see how it plays out here in the states.

That pipeline is spot on. You're more than welcome to drive the release process, others have already done lots of good work and got us integrated w/ Circle Ci - we may need more automated pre-release tasks. I'll look into the Play store upload plugin and what that requires. And the Google Play Developer Console - I think it has authorization/access controls for external devs, I'll research that out.