Skip to content
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

Support for testing versions vs production versions #15

Open
GoogleCodeExporter opened this issue Mar 14, 2015 · 5 comments

Comments

@GoogleCodeExporter
Copy link

@GoogleCodeExporter GoogleCodeExporter commented Mar 14, 2015

it would be great if there was a way for our testing deployments to see a 
different set of updates than our production deployments without needing to 
change the package name of the app for various deployments.

Original issue reported on code.google.com by d...@codesushi.com on 25 May 2012 at 7:24

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Mar 14, 2015

if you don't change the package name, how can you tell the testing version from 
production?

Original comment by lenik.terenin on 25 May 2012 at 11:51

  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect
@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Mar 14, 2015

For some services we use there is a token/id the app transmits to the service 
we swap this out durring the build process. Crittercism and Google Analytics 
for instance. 

Original comment by d...@codesushi.com on 25 May 2012 at 11:56

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Mar 14, 2015

1. when you upload a file, how our system can tell if this is a production or 
testing build? preferably without the manual input, which is too error prone.

2. when someone comes and requests an update for 'com.yourdomain.yourpackage', 
how can we tell if he's eligible for testing or production builds?

Original comment by lenik.terenin on 26 May 2012 at 12:51

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Mar 14, 2015

There would have to be 2 separate apps configured on your system with the same 
package name, but a token which somehow indicates which one to check on.  or at 
upload time, we would upload to the same app on your system but pick a user 
defined token which would allow the code to determine which uploaded updates it 
is eligible to receive. 

Original comment by d...@codesushi.com on 29 May 2012 at 2:20

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Mar 14, 2015

I think the easiest way to handle this is to have 2 areas for uploading, 
production, and testing (package names could be the same).

When doing an update, there would be a boolean in the aua class called 
something like BetaTester that is false by default.  Then in the application we 
could have a setting or switch that allows the user to choose if they want to 
receive beta pacakges.  if they say yes, then it will switch the boolean 
internally in the app to true, and that user would receive beta updates instead 
of production updates.

I think that makes the most sense and gives the developer great flexibility

Original comment by bric...@gmail.com on 29 May 2012 at 7:35

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.