Currently I am seeing long review times for our extension. Review time seems to be at least 2 weeks compared to 1-2 days for Safari and Chrome.
The issue is that we typically release 1-2 updates per week. I am wondering what the best practice is in this case?
When I submit a new version, previous un-reviewed versions get disabled. Does that mean submitting a new version reset your position in the review queue?
If yes, is it recommended to skip versions for Firefox users? I am afraid that I am stuck in a loop where my position keeps getting reset to the bottom of the review queue because we are providing frequent updates to users.
But aren’t extensions that waits already over a week specially marked for the reviewer so that he can focus on those first?
And if you release new version, it will appear as “freshly submitted” so reviewer will focus instead on those that have been waiting for longer…
(I’m only guessing here)
@juraj.masiar, what you described is essentially a first in first out queue, and yes, that’s the core of how the review queue works: older items are processed first, new items get added to the end of the queue.
But, I think you might be imagining this as a queue of submissions when it is more accurate to think of it as a queue of add-ons to review.
When a developer submits a new version for review, the extension gets added to the end of the review queue. Later, if the developer submits a new version while the extension is still queued, the extension’s queue record is updated to reference the newer version. The overall queue position remains the same, but the content being reviewed has changed. When the add-on is reviewed, it’s removed from the queue.
I meant like a new table review_jobs where id is auto-incremented integer and addon_id would be a foreign key for addons table.
So when you sort by id, you’ll get the FIFO stack .