Forum Discussion
Suggestion: Share Available Features in Each Build
There is top feedback posts in this forum where inform us on upcoming features in Microsoft Edge. I though, it would be interesting if there was something like master list of features and availability in each channel. Take a look at following example:
| Official | Beta | Dev | Can | |
| Feature 1 | coming soon | coming soon | available | available |
| Feature 2 | coming soon | coming soon | coming soon | coming soon |
| Feature 3 | available | available | available | available |
| Feature 4 | coming soon | available | available | available |
| Feature 5 | coming soon | coming soon | available | available |
This is for features which have been confirmed to be available and user want to know which feature is available in each build. We could find details from posts , but representing in above format would be more valuable for many users. This is just an idea and we could discuss on improving it. Available could show the build number and/or available date and coming soon also show estimated date where feature will be available or in case it is unknown just shows coming soon and this list could be updated regularly.
35 Replies
It won't cost much, there could be a platform to automatically mine data from sources and show them in table and it won't take too much time and man power to do that, but it is valuable.
Let me share you some use cases, normally we ask users to use stable and final build. But let say user is looking for features which are not available in stable build yet and are critical for users, in this case we might need to invest on deploying next most stable build. For example, in case we have deployment plan for next month and we will see specific feature is available in Dev and next month will be available in Beta and it might take six month to come to stable release, then we deploy Beta instead of Dev. Normally, we come across these decisions after reviewing set of features in each build release note manually and then decide. It is not only about single user with one PC, but it is about entire organization. Knowing features and supported build in one view is very helpful to make decision especially when we are planning to do massive deployment. We could do this manually by looking into such information and bring them into table and then decide, but having such information save us time.
- There is top feedback list for insiders, and Microsoft docs for stable and beta.
if user doesn't want to wait 6 weeks, then they can use Beta, change log again in Microsoft docs.
nothing can be so critical to force someone use unstable builds from Dev or Canary for their "critical" job. even if that was the case, Dev weekly change log posts and there to help.
top feedback list also has a history list.
there are a lot of important things to work on.Let me tell you one example, in production environment we always deploy stable build but users working a lot with stable build but they want PDF feature to add note. In this case, either we have to deploy third-party program like Adobe Reader or deploy the build of Microsoft Edge where support this feature or in case we know it will be available soon, wait for availability.
Once this feature becomes available in stable release we shall remove insider version. Having such feature is not consuming a lot of time but it is very valuable for users.
I am fully aware of such available resources and I am checking them regularly. However , my point is having all details in one view like the table I just mentioned. From those resources, let say you want to see which feature is available in each build, you will need to check them one by one. But from the example I just shared, you could see availability of each feature in one view rather than having to check separate resources.
And maintain useless information cost manpower, i prefer to see peoples integrate news functions than maintain an information totally useless since enterprise will only check the release note of the stable/beta version a roll it out manually.
And for technical user they will follow what information there is here or like HotCakeX as said they will see on update page.
And for normal user they don't care and many of them will not even see the browser is updated.
- I don't see any reason to know when version of Edge had which feature in a table.
features added to Stable are part of the browser now, they are usually showcased in What's New page and other Microsoft websites. lots of features are going to be added to stable.
they are well documented in Microsoft Docs (for stable/beta)
things we see for insider are also well documented in a table for Edge canary/dev, even though they are temporary.
there is no point in coming back and viewing a table that tells me web capture was added 1 year ago or sidebar was added 9 months ago. just useless info. they are all part of the Edge stable and one package.
What Wittycat said above is correct
Beta and Stable channels have their change logs with specific available features in Microsoft Docs.
Any new feature that gets crossed out on the Top Feedback list means that it is available on Edge canary, that's the starting point. Edge community moderators said that themselves.
after that, the weekly Edge dev update posts that contain change logs, precisely specify which features are available in each build.
it already exist :
Stable : Stable Channel
Beta : Beta Channel
DEV & CAN in this forum : Edge Insider Discussions.
