-
Notifications
You must be signed in to change notification settings - Fork 772
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Locking down the visual F# codebase #371
Comments
Good! the release is near 😄 , but can we have a 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 Let's use master as vnext:
now Some features/bugfix cannot enter fsharp4 ok, but wait more months is not needed |
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 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 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 |
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
The text was updated successfully, but these errors were encountered: