Published by Marco on 12. May 2016 15:13:34
Updated by Marco on 26. Sep 2016 21:21:37


Before taking a look at the roadmap, let's quickly recap how far we've come. An
overview of the release schedule shows a steady accretion of features over the
years, as driven by customer or project needs.


The list below includes more detail on the releases highlighted in the graphic.

  * "0.1" : Proof of
    concept with metadata, PostgreSql (data and schema-migration) and Winforms
  * "1.0" : First customer
    product with PostgreSql, DevExpress Winforms UI and Reporting
  * "1.0.5" : MS-SQL
    driver (parity with PostgreSql driver)
  * "1.5.0" : Remoting
    data driver; require .NET 4.0
  * "1.6.0" : Mongo/NoSQL
    data driver 
  * "1.8.0" : Rewrite data
    driver to use sessions
  * "1.8.5" : Support
    "improved metadata-generation pattern"
  * "1.9.0" : Add
    plugin/overlay support
  * "1.10.0" : Require
    .NET 4.5; add JSON-based remoting protocol; Windows-service support
  * "1.13.0" : Rewrite
    security API
  * "v2.0-beta1" : Rewrite
    configuration, logging and schema-migration APIs
  * "v2.0-beta2" : Add V2
    generated-code format
  * "2.0" : Finish
    configuration/IOC rewrite; produce NuGet packages for delivery
  * "2.2" : Stabilize
    Winform; support aliased tables in queries
  * "3.0" : Rewrite
    MetaBuilder API; improve support for plugins


We took 1.5 years to get to v1. The initial major version was to signify the
first time that Quino-based code went into external production. [2]

After that, it took 6.5 years to get to v2. Although we added several large
products that use Quino, we were always able to extend rather than significantly
change anything in the core. The second major version was to signify sweeping
changes made to address technical debt, to modernize certain components and to
prepare for changes coming to the .NET platform.

It took just 5 months to get to v3 for two reasons:

   1. Although we were able to make a lot of planned changes in v2 [3], we had
      to leave some breaking changes for future versions. [4]
   2. We now strictly adhere to the rule that a breaking change anywhere in the
      software's API -- and Quino's API surface is large -- leads automatically
      to a major-version change. [5]


So that's where we've been. Where are we headed?

As you can see above, Quino is a very mature product that satisfies the needs of
a wide array of software on all tiers. What more is there to add?

Quino's design has always been driven by a combination of customer requirements
and what we anticipated would be customer requirements.

We're currently working on the following features.

Modeling improvements

   This work builds on the API changes made to the MetaBuilder in v3. We're
   creating a more fluent, modern and extensible API for building metadata. We
   hope to be able to add these changes incrementally without introducing any
   breaking changes. [6]


      A natural use of the rich metadata in Quino is to generate user interfaces
      for business entities without have to hand-tool each form. From the POC
      onward, Quino has included support for generating UIs for .NET Winforms.

      Winforms has been replaced on the Windows desktop with WPF and UWP. We've
      gotten quite far with being able to generate WPF applications from Quino
      metadata. The screenshots below come from a pre-alpha version of the
      application included in the Quino solution.


      You may have noticed the lovely style of the new UI. [7] We're using a VSG
      designed for us by "Ergosign" , for whom we've
      some implementation work in the past.

.NET Core

   If you've been following Microsoft's announcements, things are moving quickly
      in the .NET world. There are whole new platforms available, if you target
      your software to run on them. We're investigating the next target
      for Quino. Currently that means getting the core of Quino -- Quino.Meta
      its dependencies -- to compile under .NET Core.

      [image]As you can see in the screenshot, we've got one of the toughest
      assemblies to compile -- Encodo.Core. After that, we'll try for running
      tests under Linux or OS X. The long-term goal is to be able to run
      Quino-based application and web servers on non-Windows -- and, most
      importantly, non-IIS -- platforms. [8]

      These changes will almost certainly cause builds using previous versions
      break. Look for any additional platform support in an upcoming


[1] There were, of course, more minor and patch releases throughout, but those
    didn't introduce any major new functionality.

[1] Punchclock, our time-entry and invoicing software -- and Quino ""dogfood"
    (When a developer uses their own code for their own daily needs. Being a
    user as well as a developer creates the user empathy that is the hallmark of
    good software.)" product -- had been in use internally at Encodo earlier
    than that.

[1] E.g. splitting the monolithic Encodo and Quino assemblies into dozens of
    new, smaller and much more focused assemblies. Reorganizing configuration
    around the IOC and rewriting application startup for more than just desktop
    applications was another sweeping change.

[1] One of those breaking changes was to the MetaBuilder, which started off as a
    helper class for assembling application metadata, but became a monolithic
    and unavoidable dependency, even in v2. In v3, we made the breaking changes
    to remove this component from its central role and will continue to replace
    its functionality with components that more targeted, flexible and

[1] In the years between v1 and v2, we used the minor-version number to indicate
    when breaking changes could be made. We also didn't try as hard to avoid
    breaking changes by gracefully deprecating code. The new approach tries very
    hard to avoid breaking changes but accepts the consequences when it's deemed
    necessary by the team.

[1] That is, when users upgrade to a version with the newer APIs, they will get
    obsolete warnings but their existing code will continue to build and run, as
    before the upgrade. In this way, customers can smoothly upgrade without
    breaking any builds.

[1] You may also have noticed that the "Sandbox Dialog View" includes a little
    tag in it for the "XAML Spy", a tool that we use for WPF development. Just
    so you know the screenshots aren't faked... :-)

[1] As with the WPF interface, we're likely to dogfood all of these technologies
    with Punchclock, our time-tracking and invoicing system written with Quino.
    The application server and web components that run on Windows could be
    migrated to run on one of our many Linux machines instead.