Every experimental feature graduating from experimental should be explicitly called out at the top of the log. We probably haven't been consistent in the past, but it should be easier for a release manager to remember when adjusting the list of still experimental features.
On Wed, Nov 2, 2016 at 7:06 PM, Zhitao Li <zhitaoli...@gmail.com> wrote: > (speaking from both a contributor and user perspective) > > Definitely +1 for improve visibility of experimental features, and I think > the proposal is definitely helpful for people to read it. > > In terms of expectation management, one thing from the user perspective is > when an experimental feature will graduate into stable, because a > responsible user might hold-off actual (or full) adoption until that > happens, and they need to plan accordingly. Have a way to track what items > the owner considers necessary for a feature to become stable is quite > important in such a case (not everyone has the luxury to comb through JIRA > boards for contexts, or talk to the direct owner of the the feature). > > On Tue, Nov 1, 2016 at 5:28 PM, Alex Rukletsov <a...@mesosphere.com> > wrote: > > > Folks, > > > > Additionally to the "known bugs" proposal in a parallel thread, we think > > that maintaining a list of still experimental features for each minor > > release will significantly help users > > to adjust their expectations. > > > > Our suggestion is to include a new section into the CHANGELOG called > > "Experimental Features" starting with the upcoming 1.1.0 release. > > Populating this section should be relatively easy: take the contents of > > this section from the previous minor release, remove features declared > > stable, and add new experimental features. > > > > With this change users will have a complete overview of experimental > > functionality per release, without searching the CHANGELOG for when and > > whether a certain feature became production-ready. > > > > What do you think? > > > > AlexR. > > > > > > -- > Cheers, > > Zhitao Li >
