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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1513860 Title: 'Latest' version of a click package used after reboot To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-developer-experience/+bug/1513860/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
