Suggestion: Share Available Features in Each Build

Bronze Contributor

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:

 

 OfficialBetaDevCan
Feature 1coming sooncoming soonavailableavailable
Feature 2coming sooncoming sooncoming sooncoming soon
Feature 3available available availableavailable
Feature 4coming soonavailable availableavailable
Feature 5coming sooncoming soonavailable 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 already exist :

Stable : Stable Channel
Beta : Beta Channel
DEV & CAN in this forum : Edge Insider Discussions.

@Wittycat Available features...

@Kam 


@Kam wrote:

@Wittycat Available features...


Those websites he mentioned are for available features.

@Reza_Ameri-Archived 

What @Wittycat said above is correct

https://techcommunity.microsoft.com/t5/discussions/suggestion-share-available-features-in-each-build...

 

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.

@HotCakeX No, I thought they're for new features.

They are relatively new, to each version.

@Wittycat @HotCakeX 

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.

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.

@Reza_Ameri-Archived 

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.

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.

The problem is that the official Release Notes for Stable and Beta releases is not the complete list. It is geared more towards Enterprise feature/changes. I noticed this on the first release that it doesn't show all the bug fixes and was missing features that was clearly rolled out. For example, the Favorites menu is fully rolled out but not documented as such.

 

The Dev Change list and Feedback list is the most clear picture of tracking changes. My suggestion is that the Feedback List gain a column that indicates Can/Dev/Beta/Stable and then that can be used to help update the Release Notes documentation for Beta and Stable.

@dragonwolf83 

Spoiler

@dragonwolf83 wrote:

The problem is that the official Release Notes for Stable and Beta releases is not the complete list. It is geared more towards Enterprise feature/changes. I noticed this on the first release that it doesn't show all the bug fixes and was missing features that was clearly rolled out. For example, the Favorites menu is fully rolled out but not documented as such.

 

The Dev Change list and Feedback list is the most clear picture of tracking changes. My suggestion is that the Feedback List gain a column that indicates Can/Dev/Beta/Stable and then that can be used to help update the Release Notes documentation for Beta and Stable.




Yeah they can add an extra column to the top feedback list, but the favorites menu is a different matter.

they are knowingly/unknowingly running controlled feature rollout experiments in the stable channel.

I asked developers in the forum many times but none of them are responding, they all ignore that specific question, which is kind of suspicious, no one is denying nor confirming it, they all ignore. 

 

this has never happened before:

https://techcommunity.microsoft.com/t5/discussions/why-is-edge-87-stable-channel-running-experiments...

 

@Deleted @johnjansen 

 

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.

in that example there is no need for this. just install insider builds and you will find out which one has it, And also read the change logs.
before deploying anything, you have to test it so you will know.

Yes, this is exactly what we are doing, we trying all builds and check release notes and they make decisions but having such a table would make our jobs a lot easier and I believe it is the same for other users.

In addition, this could be data retrieval and could be done automatically.

That's not how it works.
in business environments, people don't make decisions based on things that exist in Dev and Canary channels. even Edge developers don't know which features are going to be added to which Stable channel exactly, until they experiment with them a lot and receive data from users.
things that are in Dev and Canary can be removed at any time or something else replace them, or get delayed by a couple of months.

this is why this chart or whatever is useless, Specially for businesses.

the only concrete information businesses need, and I'm talking from experience, is the change log that is official and exists in Microsoft Docs.

the same thing applies to Windows channels (Dev/Beta/Release Preview).
anything in the Dev channel is subject to change/removal at any time.

It is not the way you said.

There are features we are sure will be available in stable release but might subject to change like add note to PDF or table of content.

It is also important to have such table to be able to provide valuable feedbacks. So let say we know this feature is available in which channel and we know exactly what channel we have to test and in large scale such data are very valuable.

It is exactly like what I described, because that's how it is in reality. it has nothing to do with feedbacks.
things that are in Dev and Canary can be removed at any time or something else replace them, or get delayed by a couple of months.