So I have a few scenarios this has happened, in the music app and other
core apps the bzr revision number is used as the sub version, for
example {major}.{minor}.{bzrrevno}.The first example is from the music-app, the store currently is of the version 2.2.910 but I'm working on the music-app background playlists which is (currently) of the version 2.2.905. Then each day when media- hub is updated I must install the deb packages and restart the device this then causes it to flip back to the version from the store. It is incredibly confusing and wastes a lot of developer time checking that I'm actually launching the correct app. The second example is that the store has 2.2.910, then if I am developing from Qt Creator this will install 2.2.latest but then if developer another feature and install manually that could then be 2.2.930. However overnight I then get a OTA system update, restart my device and I'm now on 2.2.latest as that is the 'latest' version, now if I was trying to test the 2.2.930 I now have to repush a click over again. I believe that whatever was the last manually installed click version to be installed should be selected to be run. Changing the version of the click package also wastes time, as this has to be done after you have committed the code but before you build the click package. Furthermore as seen in the second example, if I select a random larger number I must then keep selecting equal to or larger version. The solution that Qt Creator uses with the .latest suggests that maybe, if you are side-loading applications they should have a special version that is always higher as a solution. Please let me know if you need more developer use cases. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to click in Ubuntu. https://bugs.launchpad.net/bugs/1513860 Title: 'Latest' version of a click package used after reboot Status in Client Developer Experience: New Status in Canonical System Image: Incomplete Status in click package in Ubuntu: Incomplete Bug description: The 'latest' version of a click package is used after a reboot, even when a click with a lower version has been manually installed. What happened: 1) Install a click packages for an existing application with a lower version than that of the preinstalled one 2) Launch the app and notice that the newly installed is launched 3) Reboot the device 4) Launch the app and notice that the preinstalled one is used due to it having a higher version What was expected to happen: At step 4) for the manually installed version of the click package to still be the selected one This affects the developer experience for example, when working on the bgplaylists of the music-app the branch has a lower version (bzr rev) than trunk/what is in the store, and after installing new versions of media-hub to test the device must be restarted. So after each restart the developer must also remember to reinstall the click package. $ apt-cache policy click click: Installed: 0.4.40+15.04.20151006-0ubuntu1.1 Candidate: 0.4.40+15.04.20151006-0ubuntu1.1 Version table: *** 0.4.40+15.04.20151006-0ubuntu1.1 0 1001 http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu/ vivid/main armhf Packages 100 /var/lib/dpkg/status 0.4.38.5ubuntu0.2 0 500 http://ports.ubuntu.com/ubuntu-ports/ vivid-updates/main armhf Packages 500 http://ports.ubuntu.com/ubuntu-ports/ vivid-security/main armhf Packages 0.4.38.5 0 500 http://ports.ubuntu.com/ubuntu-ports/ vivid/main armhf Packages To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-developer-experience/+bug/1513860/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
