Community
Participate
Working Groups
On Metrics page, we have access to the number of installations of a marketplace entry. it would be nice to provide count for updates too. it will allow to compare more easily with other IDEs that are providing numbers mixing installations+updates (and which are by consequence far higher). As a lot of people are unfortunately comparing directly the marketplace numbers with the other IDEs number (for instance with VS Code)
I am moving this request to MPC since MPC will need to build a mechanism that will report back to marketplace.eclipse.org when a listing is updated. I assume we would want to track updates and install separately? If so, we will need to update/create an endpoint on marketplace.eclipse.org.
Depending on the expectation about these numbers, this could get tricky. If the expectation is just to count each time someone active clicks on "Update" on an installed item in MPC, then it's trivial. However, I would expect that the vast majority of updates for items installed through MPC are NOT explicitly performed via MPC, but get installed through the regular "Check for Updates", which runs automatically once per week by default and can be triggered manually through "Help / Check for Updates". This flies completely past MPC. I think I can hook a listener into P2 to be informed of any installs/updates and then check if this concerns any installed Marketplace items that we know about. In that case, we should be able to count these updates against Marketplace items. However, this still has a similar matching issue as correlating installed plug-ins with Marketplace entries - i.e. if a Marketplace entry consists of multiple plug-ins, when does it count as installed? Depending on how we count, I could see this artificially inflating update numbers in some cases. Right now, we use a notion of "required plug-ins" to decide on the "Installed" state, but consider any update to any (even non-required) plug-in of an entry a potential update case for which we show the "Update" button.
(In reply to Christopher Guindon from comment #1) > > I assume we would want to track updates and install separately? If so, we > will need to update/create an endpoint on marketplace.eclipse.org. It will be the best if we can count them separately. it will be even better than what competitors are providing. (In reply to Carsten Reckord from comment #2) > Depending on the expectation about these numbers, this could get tricky. > > If the expectation is just to count each time someone active clicks on > "Update" on an installed item in MPC, then it's trivial. I think it can be a first iteration, it needs to be clear in UI that it is counting only this use case. (In reply to Carsten Reckord from comment #2) > However, I would expect that the vast majority of updates for items > installed through MPC are NOT explicitly performed via MPC, but get > installed through the regular "Check for Updates", which runs automatically > once per week by default and can be triggered manually through "Help / Check > for Updates". This flies completely past MPC. Agree (In reply to Carsten Reckord from comment #2) > I think I can hook a listener into P2 to be informed of any installs/updates > and then check if this concerns any installed Marketplace items that we know > about. In that case, we should be able to count these updates against > Marketplace items. it seems to be the best option. (In reply to Carsten Reckord from comment #2) > However, this still has a similar matching issue as correlating installed > plug-ins with Marketplace entries - i.e. if a Marketplace entry consists of > multiple plug-ins, when does it count as installed? Depending on how we > count, I could see this artificially inflating update numbers in some cases. > Right now, we use a notion of "required plug-ins" to decide on the > "Installed" state, but consider any update to any (even non-required) > plug-in of an entry a potential update case for which we show the "Update" > button. and you are pointing a tough issue. For sure it is better to count it a single time. Maybe there is also an update time or id that can be used to avoid counting them several times? Or it might be possible to provide it so we can count for future version of Eclipse at least. (a very rough guess as I have nerver seen the code)
The update strategy is handled purely by p2. One can already enable download stats on p2 to infer the number of updates. I don't think MPC can help here, and it seems to me p2 has already a solution for that.
*** Bug 558366 has been marked as a duplicate of this bug. ***
