Win2D after V1


Win2D is rapidly approaching a V1 release – just a few loose ends to tidy up first.

In some ways “release” doesn’t mean much for an agile project like this, where we’ve been shipping new versions roughly every two weeks.  We will bump the version number from 0.0.x to 1.0.0, post an “ok, here is V1” announcement, then go right back to work adding more features (as you can see from the backlog, we have plenty still to do).

For us V1 means that:

  1. We have finished enough features to allow the creation of rich, interesting apps
  2. We believe in the design of these features, and don’t plan on changing them any more
  3. The implementation is robust and high quality

We aren’t promising 100% compatibility from V1 until the end of time, but want to provide a stable API with far fewer breaking changes than you have seen so far.  Which begs the question, how do we maintain a stable V1 feature set in parallel with ongoing development of experimental new things?  The ability to try things out, ship early and often, and respond to feedback has been valuable to this project, so I don’t want to lose that.

The traditional option is to maintain two branches: current stable and experimental vNext.  But we are a small team, and maintaining two things in parallel is a tax that would slow our overall progress.  This could also dilute the value of customer feedback, as many customers would no longer be using the version we were actively working on.

Instead, I propose we just plow ahead with a single version.  Two weeks after releasing V1, we will ship a 1.1.0 update, which will add experimental new features over the top of the stable V1 feature set.  We will document which APIs are stable versus new and liable to change, but everything will live together in a single branch and we will only ship a single latest-and-greatest NuGet package.  This means Win2D will not follow semantic versioning, because we’ll have no way to indicate via a single version number that some parts of the package are stable while others are experimental.

Please share any thoughts or concerns in the comments below.


Comments (5)

  1. Matt Robinson says:

    I've been waiting for an 'easier' alternative to Direct2D for years. Great work guys!

  2. Kevin Gosse says:

    Ideally, the experimental APIs could be shipped in a separate DLL, using extension methods and InternalsVisibleTo. That would be the best way to avoid any confusion between stable and experimental APIs, while not going through the pain of maintaining two distinct branches. Most developers would use the main stable DLL, and those in need of more advanced features would add the experimental DLL, to their own risk.

  3. Markus Ewald says:

    Even if documented, I think it would be troublesome if experimental features would be found side by side with stable features.

    Maybe you could adopt a convention from other languages where in-development features are put into a namespace 'Future' (eg. Win2D.Something.Future) until they are complete and their API has stabilized?

    Then, simply by avoiding any 'Future' namespaces, one could build against the stable version of Win2D.

  4. Anastasios-Antonios Toulkeridis says:

    I know win2d has nothing to do with 3D graphics but -and forgive me if it is a naïve question- do you think it could be used for VR?  (e.g. Oculus Rift).   The way I understand it if you want to create a simple app for VR you have to choose either Unity or Unreal Engine 4. It would be nice if we could create something simple for the Oculus Rift using Win2D

  5. RobMc says:

    My opinion is for the short term and near term keep the fast progression.  Long term tighten once you have critical mass.

    I say the speed is the value here for now since after this api is so easy to use that changes aren't that big of a deal to absorb on my end.

    regards,

    rob

Skip to main content