Opened on 10/19/2016 at 10:53:56 AM

Closed on 02/25/2017 at 12:31:56 AM

#4549 closed change (fixed)

Implement the Windows Store API to upload development builds

Reported by: sebastian Assignee: oleksandr
Priority: P2 Milestone:
Module: Sitescripts Keywords:
Cc: kvas, oleksandr, wspee, trev Blocked By:
Blocking: #4626 Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by sebastian)


For Chrome and Firefox, the development builds are automatically generated and submitted to the respective stores, once new changes landed in the repository. However, for Microsoft Edge, development builds are still generated and published manually.

What to change

Implement the Windows Store API in order to automatically upload development builds for Microsoft Edge, similar to how we did it for the Chrome Web Store.

Since the Windows Store requires the fourth part of the version number to be 0 (see below), the revision number should replace the third part, instead of being added as fourth part like we do for other devbuilds.

Attachments (0)

Change History (18)

comment:1 Changed on 10/24/2016 at 01:52:13 PM by kvas

  • Owner set to kvas

comment:2 Changed on 11/14/2016 at 01:10:50 PM by jsonesen

  • Blocking 4626 added

comment:3 Changed on 12/19/2016 at 04:16:38 PM by sebastian

  • Cc wspee trev added
  • Owner changed from kvas to sebastian

I unassigned kvas, who didn't start to work on this issue yet and is on vacation now. However, wpsee told me that he might be interested to work on this. ;)

But at least one more thing we need to agree on, is the version scheme of development builds for Microsoft Edge. So far our development builds use version numbers consisting of 4 parts (e.g. where the last part is the revision number from Mercurial. However, as it turned out meanwhile, the Windows Store requires all version numbers to have 4 parts where the last part must be 0 (it is meant for internal use by the Windows Store). The probably most pragmatic approach would be to just ignore the third part for development builds for Microsoft Edge, so Adblock Plus for Chrome would be equivalent to Adblock Plus for Microsoft Edge 1.12.1702. Or we could take this opportunity, to simplify our version numbers all together, so that release versions have only 2 parts, and development versions 3 parts (with the last one being the revision), for all platforms or at least those based on adblockpluschrome (for now).

Last edited on 12/19/2016 at 04:28:13 PM by sebastian

comment:4 Changed on 12/19/2016 at 04:16:56 PM by sebastian

  • Owner sebastian deleted

comment:5 Changed on 12/19/2016 at 04:31:22 PM by oleksandr

I wouldn't mind working on this as well. Also, I think just ignoring the third part in our versioning is good enough.

comment:6 Changed on 12/20/2016 at 08:00:02 AM by wspee

I don't really mind. Is this something that is needed for the upcoming edge release? Then it might be better to let @oleksandr do it? On the other hand he might have a lot to do already?! Either way just let me know.

comment:7 follow-up: Changed on 12/20/2016 at 03:22:59 PM by sebastian

  • Description modified (diff)

I don't mind who is going to work on this. Though somewhat important, it is not ridiculously urgent. We'd just have keep preparing development builds manually, as we did so far for Microsoft Edge, until this has been implemented. Also it probably won't be any quicker dependent on who of you are working on it, as both of you seem to not be too familiar with our sitescripts and buildtools. ;)

I am not too happy with the situation with the version number, but nobody seems to have any better idea. So I updated the description accordingly, so that we replace the third part of the version number.

comment:8 in reply to: ↑ 7 Changed on 12/20/2016 at 03:32:29 PM by oleksandr

I can find other stuff to work on. I just wanted to make sure we'll get Edge devbuilds from adblockpluschrome ASAP, so thought I might help out here. If you're fine doing it manually then the priority of this is not really P2, I guess.

comment:9 Changed on 12/20/2016 at 04:45:31 PM by sebastian

Of course the current situation isn't great, and something we should tackle soon. But it's not that there is much we can do to speed it up, in particular with the upcoming holiday season. However, before this is going to block anything, we have at least the option to manually publish a development build if necessary. Anyway, I guess, whoever of you gets first the chance to start working on this, just assigns the issue to himself.

Last edited on 12/20/2016 at 04:47:03 PM by sebastian

comment:10 Changed on 12/27/2016 at 11:16:48 AM by oleksandr

Whoever starts working on it will need tenant ID, client ID and key based on documentation here:

An Azure Active Directory Global Administrator should be able to retrieve that. Sebastian, would you be able to retrieve it?

comment:11 Changed on 12/27/2016 at 09:34:29 PM by sebastian

I gave you the Manager role in the Windows Store, for now. As far as I understand, you should be able to retrieve those data yourself, now.

comment:12 Changed on 12/28/2016 at 05:17:14 PM by oleksandr

  • Owner set to oleksandr

comment:13 Changed on 01/18/2017 at 10:12:14 PM by oleksandr

Our Azure account is not allowed to automate Windows Store submissions through the API. See the paragraph here:


This API can only be used for Windows Dev Center accounts that have been given permission to use the API. This permission is being enabled to developer accounts in stages, and not all accounts have this permission enabled at this time. To request earlier access, log on to the Dev Center dashboard, click Feedback at the bottom of the dashboard, select Submission API for the feedback area, and submit your request. You'll receive an email when this permission is enabled for your account.

Currently I am getting an error 'Authorization: Account is not allowed to access this api'. I have submitted a request to enable the API for us, but did not receive any results yet.

comment:14 Changed on 02/06/2017 at 10:44:49 PM by oleksandr

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

comment:15 Changed on 02/16/2017 at 01:27:35 PM by abpbot

comment:16 Changed on 02/16/2017 at 01:48:25 PM by oleksandr

  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:17 Changed on 02/24/2017 at 04:37:24 PM by sebastian

  • Resolution fixed deleted
  • Status changed from closed to reopened

The devbuild that has just been published by the automation has the version number This version number doesn't contain the source control revision. So once the next commit is pushed, and a new devbuild is created, it would have the same version number.

As discussed above, due to limitations of the Windows Store, the version number must have have exactly 4 parts, with the fourth part always being 0. Hence, we agreed, as specified in the description of this issue, to replace the third part with the revision, i.e. 0.9.1727.0.

If this should no longer be necessary the version should be Either way, it is essential to have the revision in the version number of devbuilds.

comment:18 Changed on 02/25/2017 at 12:31:56 AM by sebastian

  • Resolution set to fixed
  • Status changed from reopened to closed

According to Ollie, the actual version number is, merely in the Windows Store developer login (where I have checked), the version number is truncated. Sp this should be fine.

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from oleksandr.
Note: See TracTickets for help on using tickets.