I have uploaded my apk-file as release version and published it. After some time(half day) I unpublished it to fix something. Now, 1 week later, I want to publish it again.
Would it affect promotion? I heard that "new, just published" applications have more chances to get to top apps list.
So, if I publish my application again, it would be "new app", or only first publish considered?
I have not noticed any "penalty". Amount of installs per day grows as it was in first time.
Related
Few minutes ago I know that Quality checklist of Google Play Game Services has been updated last week. Only thing what I need is what things are changed through the latest update on it. Is there any way to pick the point?
Unfortunately, there's no list of revisions or previous doc versions that you can see to check for update notes with regard to Quality Checklist. Unless, you manually save the updates every time and compare.
I've been working on using Xcode server to build my app, and have been running into some snags. The most recent involves Bots running over-zealously. I'll commit and push one change to one file, and two builds get triggered, separated by a minute or two. This also happens if I click the "Integrate Now" button, or if I make changes to the bot, with "Integrate immediately" unchecked.
Since my build takes a while to run, this is a pretty big problem, especially when I'm trying to iterate on Bot configuration.
Is anyone aware of what process triggers builds, or how can I troubleshoot this type of failure in general? It seems like there are multiple daemons listening for the signal to trigger the build or something like that.
Since it may be a bug in the Xcode beta, I submitted a radar (rdar://20456212)
I had the same problem. I changed the bot so that it does not do a clean for each integration and now it only does one build per commit. My guess is that the clean process and download of code was taking so long that the bot was being triggered before it was complete. So now I clean once a day and I only get a double build on the first build of the day. Hope this helps.
Hi trying to implement TFS for my team (18 members).
I made two branches
1) Main branch
2) Dev branch
We are using Agile.
So there is a sprint every week. And on every Thursday i merge changes from Dev to main Branch.
Each developer works on different user story. if he completes a task and check in all changes (5 files). change set (e.g 62) is generated. But tester reported a bug while unit testing. Developer fix the error and check in 1 file. it generated a new change set (e.g 63).
Problem is when i am merging user story's change to main branch i am confused with which change set to move. (62,63....)
what i do is compare whole project. which is headache some times.
Can some one suggest better way. Or i am missing something? any blog that can help
Thanks
If you have a single DEV branch, that implies that you should be merging the whole branch and all changes to MAIN (not cherry-picking, which is what you seem to be describing).
If you want the flexibility to merge only changesets relating to certain stories/bugs, then you should adopt a different branching pattern such as branch by feature.
You need to change the way that you build and deliver software in order to deliver more successfully.
http://nakedalm.com/avoid-pick-n-mix-branching-anti-pattern/
What you are describing with picking changesets will consistently and continuously reduce the quality of your product.
If you implement a good definition of done and get your guys working in a team rather than independently you should have working software at the end of each sprint. Just before the Sprint review (just in time) you should merge everything from dev to main maybe using a changset as a watermark. If you have stories in your sprint that go towards features that are not ready yet then you should hide them behind feature flags and ship.
If this sounds to hard, or something that "will not work here", or you think "or product is more complicated than that", then you are likely suffering from significant technical debt and you need to pay that back untill you give your Product Owner the choice to release everything at the end of every sprint.
My application is a combination of Spring/Hibernate/JPA. Recently my development environment was migrated to RAD 7 with WAS7. Previous I was using v.6 for RAD & WAS.
The problem is,
when I make a Java change, the server publishes for a long time, sometimes it takes upto 10 mins for a single line of change to take effect. Also even JSP changes alone takes much time during publishing!!
This was not the case in WAS6. Publishing java changes was not even a concern in WAS6. The changes takes effect immediately as the publish process is done within a few seconds.
This publishing process keeps on running several times as I make changes in my code, and I have to wait (for long intervals during work hours) till it completes, to verify/test my changes during runtime. This is horrible!!
Is there a way to make WAS7 publish JSP/Java changes faster in few seconds as like WAS6? Is there any fix/refresh pack for this?
Can someone help me with this?
Thanks in adavance.
This problem can be overcome if you have the control to publish rather than automatically publishing it. You can wait to make all your changes and then publish it.
To do that
In the server view double click on the server that you are working on and under publishing check the option "Never publish automatically".
Also if you can give the option "Run server with resources within the workspace" that would do reduce the time of copying the files from your workspace to server space while publishing.
We do use TFS to do automatic build and tests with our checkins.
Today we verified old builds we have done last week. We were seeking one specific : 2010/10/27 (5). For some kind of reason it was not showing when we opened TFS/Project/Builds in visual studio (or the build tab in TFS Web).
Here is a screenshot that shows what we saw:
(Bigger screenshot here : http://i55.tinypic.com/35lt1z6.png )
For some reason some builds are jumping, tho I can attest that each builds are iterating and on the 27th there was a 5th build.
Is there something that can prevent TFS from showing complete builds history ?
Did you check the retention policy? It removes builds when there are more then N builds.
Look at the Date Filter drop down at the upper right corner of your screen shot which is currently set for last 7 days.
It may sound obvious, but if you didn't lock the build, then it's also pretty easy to press delete on it (although hopefully the confirmation dialog would save you).
If the build's drop folder is still in your file system, then pretty much all the information on the build is still safe, even if the build has been dropped from your TFS database.
(The only problem I've seen with TFS (2005/2008/2010) is that even if you delete builds, they still show up in the WorkItem user interface so testers have to try to choose the build name from a nearly infinite list - so of course they type something sort-of-like the build number into the field. Sigh)