Locking down the visual F# codebase

[KevinRansom]

Hi,

we are at the part of our release cycle where we become very hardcore about which changes we accept into the codebase. The reason we do this is that we do not want to run the risk of breaking the product build, and losing valuable days of product testing for cosmetic changes to the code.

We do still want bug fixes and changes that tangibly improve the customer experience of the product are very much valued at this time. However, cosmetic changes, cosmetic refactoring, renaming of files will have to wait until v.next.

Over the years we have lost many days of product testing due to build breaks that the developer and all of the code reviewers were convinced shouldn't have hurt anything, and so we get paranoid about now. That is why we raise the bar on check-ins the closer we get to release.

Please continue to look over the bug list, investigate the issues and try to find fixes. We aim to ship with the highest quality we have ever achieved.

Thank you

[enricosada]

Good! the release is near 😄 , but can we have a vnext branch pls?

I know the focus is on fsharp4, np about that ( i need to push a pr for a bug btw :D ) but can you create an unstable branch or use master for vNext? vnext pr are annoying because two months from now we need to rebase and retest another time.

Let's use master as vnext:

• branch fsharp3.1 from master ( fsharp3.1 = stable branch for 3.1)
• merge fsharp4 in master

now master can accept pr for vnext (netcore/cleanup/features), and fsharp4 is locked down for next version. Also no need to change build server or anything

Some features/bugfix cannot enter fsharp4 ok, but wait more months is not needed

[enricosada]

A related issue.

Can we create an high level roadmap pls? wiki/github page, maybe some github milestones for backlog/fsharp4/vnext and highlevel issues (netcore/asp.net vnext/big features/ideas)?

Or a chat with team+contributors and a log.

Different people can help with different skills.

Someone can contribute with an improvement or features for next version but is not going to help with bugfix on fsharp4. I think that's ok if this does not create regression on fsharp4 release.

I know i cannot fix some fsharp4 bugs (i focus on vs extension/crossplat for now because i need to understand the codebase).
I can try to fix some, but others are going in next version (too much refactoring/etc).

I know we already discussed it in #265 and other issues for next version like #334 #323 #262 #264 #263 etc but with no actionable results (issues are sleeping with discussion tag)

Now fsharp4 is bugfix only, but some bug can be fixed with new features (like folders in vs project) and some other need to be future prof (like my, useless now, port of test suite to nunit, but that's ok, i not asked before start implementing it).

This need only a bit of communication, a project is not only small bugfix, otherwise is boring