Remaining work for F# 4.0 #386

Closed
latkin opened this Issue Apr 28, 2015 · 1 comment

Comments

Projects
None yet
2 participants
@latkin
Contributor

latkin commented Apr 28, 2015

We are at the tail end of the Visual F# 4.0 development cycle, but there is still work to be done. Below, I've shared the remaining test/lockdown items that need to be completed as we approach the finish line.

Some of this needs to be done using internal tools or resources, but much of it would benefit from help by the community. I've tried to make it clear where we would love help.

As this work gets done, I'll try to keep the check boxes up to date so we can see progress :-)


  • Finish up remaining small features
    • Complete, final feature work has been merged
  • Bug fixing
    • Bug fixes and low-risk performance improvements will continue to be welcome until the very end
    • There are still up for grabs issues available!
    • Action:
      • Fix bugs: everybody
  • Focused test pass at downlevel F# targeting
    • We have historically found downlevel F# targeting to be a high-risk scenario:
      • Using vCurrent compiler to interact with vPrevious runtime
        • Consuming libraries built with F# 3.1- from F# 4.0
        • Using F# 4.0 to create libraries targeting F# 3.1-
      • Using vPrevious compiler to consume output of vCurrent compiler
        • Using F# 3.1- to reference libraries built in F# 4.0
    • Lots of runtime and compiler changes for 4.0 => particularly high risk
    • Action:
      • Test your libraries and apps in cross-targeting situations: everybody
      • Coverage via test automation: @latkin
  • Fix up internal IDE tests
    • We have decent IDE scenario tests that are still closed-source
    • They have bit-rotted somewhat during F# 4.0 development
    • Action:
      • Get the test up and running again: @latkin
      • Add any appropriate new tests: @latkin
  • Final all-up test pass
    • Run-through of all test automation on top OSes: Win7, Win8.1, Win10
    • Spot check of various key end-to-end scenarios
      • Project upgrade/round-trip
      • Express SKUs
      • Type provider dialog
    • Action:
      • Test automation on supported OSes: @latkin
      • Trying out end-to-end scenario: everybody
  • Check-offs for internal release criteria
    • Lots of Microsoft-internal tools and release criteria that need to be tracked and handled
      • Localization
      • Security
      • Accessibility
      • etc
    • Action:
@theoy

This comment has been minimized.

Show comment
Hide comment
@theoy

theoy Apr 28, 2015

Nice writeup, Lincoln 👍 😄.

Definitely looking forward to wrapping up the first release of F# 4!

theoy commented Apr 28, 2015

Nice writeup, Lincoln 👍 😄.

Definitely looking forward to wrapping up the first release of F# 4!

@latkin latkin added the discussion label Apr 30, 2015

@latkin latkin added this to the VS 2015 milestone Apr 30, 2015

latkin added a commit that referenced this issue May 19, 2015

Automated cross-version testing for FSHARPQA suite
Implementation of automated cross-F#-version testing mentioned in #386. This is adapted from an existing strategy used in the past for validating cross-CLR-version scenarios.

Approach ("downtarget")
 - Build each test case against vPrevious FSharp.Core (4.3.1.0 for now)
 - Run resulting EXE as-is, it will bind to vPrevious

Approach ("redirect")
 - Build each test case against vPrevious FSharp.Core (4.3.1.0 for now)
 - Run resulting exe inside of process that targets vCurrent, with binding redirects

closes #446

commit 423c10d2550bfbdbb6bedd406e56e3d928dd72cb
Author: latkin <latkin@microsoft.com>
Date:   Mon May 18 15:27:53 2015 -0700

    Removing from CI build

commit e29e727a7b64d2215fca7ee61bd6f5805fe82c3b
Merge: 133a57a db6c198
Author: latkin <latkin@microsoft.com>
Date:   Mon May 18 15:26:27 2015 -0700

    Merge branch 'crosstarget-test' of https://github.com/latkin/visualfsharp into latkin-crosstarget-test

    Conflicts:
    	tests/fsharpqa/Source/CodeGen/EmittedIL/Misc/env.lst

commit db6c198
Author: latkin <latkin@microsoft.com>
Date:   Tue May 12 17:06:34 2015 -0700

    More script fixes

commit 105051f
Author: latkin <latkin@microsoft.com>
Date:   Tue May 12 16:29:03 2015 -0700

    Fix for RunTests.cmd

commit 65c8453
Author: latkin <latkin@microsoft.com>
Date:   Tue May 12 15:39:30 2015 -0700

    Omit some cases from CI build

commit a86ef97
Author: latkin <latkin@microsoft.com>
Date:   Tue May 12 14:17:07 2015 -0700

    Add to CI build (can be removed)

commit ab100d2
Author: latkin <latkin@microsoft.com>
Date:   Tue May 12 14:16:49 2015 -0700

    Update log paths

commit 4fe04d6
Author: latkin <latkin@microsoft.com>
Date:   Tue May 12 14:12:24 2015 -0700

    Comment, use better name for test suites

commit 907c11d
Author: latkin <latkin@microsoft.com>
Date:   Tue May 12 13:58:46 2015 -0700

    Using exe impl of ExecAssembly, much faster, allows for easier platform targeting

commit e5041d4
Author: latkin <latkin@microsoft.com>
Date:   Mon May 11 17:36:40 2015 -0700

    Support for targeting downlevel, then executing redirected back to vCurrent

commit 3577b5a
Author: latkin <latkin@microsoft.com>
Date:   Mon May 11 16:38:25 2015 -0700

    Detect obviously incompatible test cases in RunAll, instead of requiring annotation

commit 883e1bc
Author: latkin <latkin@microsoft.com>
Date:   Mon May 11 16:21:53 2015 -0700

    Marking more tests that can't be run cross-version

commit 3ed9c09
Author: latkin <latkin@microsoft.com>
Date:   Fri May 8 17:53:06 2015 -0700

    Start ignoring certain tests that do not support cross-version

commit ae153f3
Author: latkin <latkin@microsoft.com>
Date:   Fri May 8 17:50:05 2015 -0700

    Add support for auto-tagging a test with 'FSI' based on presence of 'FSIMODE' var

commit 63753f3
Author: latkin <latkin@microsoft.com>
Date:   Fri May 8 16:10:39 2015 -0700

    Updates to RunTests for cross-targeting

commit 46c786b
Author: latkin <latkin@microsoft.com>
Date:   Fri May 8 15:10:53 2015 -0700

    Fixing specification of compiler flags in tests

    SCFLAGS should be used by individual tests to specify required compiler or fsi flags
    ISCFLAGS and IFSIFLAGS should be reserved only for infrastructure use, they apply globally

    ISCFLAGS was populated with '-g --optimize' (emit debug info and enable
    optimizations), but is now clear.  A few tests now need to specify
    these flags explicitly.  This is a better default - tests should not need
    to rely on or know about globally defined flags.

commit 118c1f0
Author: latkin <latkin@microsoft.com>
Date:   Tue May 5 17:37:08 2015 -0700

    Start working on cross-targeting automation

@latkin latkin closed this Jul 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment