<h>History</h> 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. <img src="{att_link}quino_change_log_timeline.png" href="{att_link}quino_change_log_timeline.png" align="none" caption="Timeline"> The list below includes more detail on the releases highlighted in the graphic.<fn> <ul> <b><a href="{app}view_article.php?id=271">0.1</a></b>: Proof of concept with metadata, PostgreSql (data and schema-migration) and Winforms UI <b><a href="{app}view_article.php?id=281">1.0</a></b>: First customer product with PostgreSql, DevExpress Winforms UI and Reporting <b><a href="http://encodo.com/en/blogs.php?entry_id=228">1.0.5</a></b>: MS-SQL driver (parity with PostgreSql driver) <b><a href="http://encodo.com/en/blogs.php?entry_id=255">1.5.0</a></b>: Remoting data driver; require .NET 4.0 <b><a href="http://encodo.com/en/blogs.php?entry_id=256">1.6.0</a></b>: Mongo/NoSQL data driver <b><a href="http://encodo.com/en/blogs.php?entry_id=230">1.8.0</a></b>: Rewrite data driver to use sessions <b><a href="http://encodo.com/en/blogs.php?entry_id=233">1.8.5</a></b>: Support <a href="{app}view_article.php?id=2720">improved metadata-generation pattern</a> <b><a href="http://encodo.com/en/blogs.php?entry_id=246">1.9.0</a></b>: Add plugin/overlay support <b><a href="http://encodo.com/en/blogs.php?entry_id=354">1.10.0</a></b>: Require .NET 4.5; add JSON-based remoting protocol; Windows-service support <b><a href="{app}view_article.php?id=3052">1.13.0</a></b>: Rewrite security API <b><a href="{app}view_article.php?id=3128">v2.0-beta1</a></b>: Rewrite configuration, logging and schema-migration APIs <b><a href="{app}view_article.php?id=3142">v2.0-beta2</a></b>: Add V2 generated-code format <b><a href="{app}view_article.php?id=3194">2.0</a></b>: Finish configuration/IOC rewrite; produce NuGet packages for delivery <b><a href="{app}view_article.php?id=3262">2.2</a></b>: Stabilize Winform; support aliased tables in queries <b><a href="{app}view_article.php?id=3260">3.0</a></b>: Rewrite MetaBuilder API; improve support for plugins </ul> We took 1.5 years to get to <b>v1</b>. The initial major version was to signify the first time that Quino-based code went into external production.<fn> After that, it took 6.5 years to get to <b>v2</b>. 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 <b>v3</b> for two reasons: <ol> Although we were able to make a lot of planned changes in <b>v2</b><fn>, we had to leave some breaking changes for future versions.<fn> 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.<fn> </ol> <h>Roadmap</h> 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 <i>be</i> customer requirements. We're currently working on the following features. <dl dt_class="field"> Modeling improvements This work builds on the API changes made to the <c>MetaBuilder</c> in <b>v3</b>. 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.<fn> WPF / VSG <div> 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 <abbr title="Windows Presentation Framework">WPF</abbr> and <abbr title="Universal Windows Platform">UWP</abbr>. 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 Sandbox application included in the Quino solution. <img attachment="sandbox_date_picker.png" align="left" caption="Sandbox Date Picker"><img attachment="sandbox_dialog_view.png" align="left" caption="Sandbox Dialog View"><img attachment="sandbox_edit_view.png" align="left" caption="Sandbox Edit View"><img attachment="sandbox_list_view.png" align="left" caption="Sandbox List View"> <clear>You may have noticed the lovely style of the new UI.<fn> We're using a <abbr title="Visual Style Guide">VSG</abbr> designed for us by <a href="http://www.ergosign.de/">Ergosign</a>, for whom we've done some implementation work in the past.</div> <clear>.NET Core <div>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 platforms for Quino. Currently that means getting the core of Quino---<c>Quino.Meta</c> and its dependencies---to compile under .NET Core. <img attachment="compilingdotnetcore.png" align="left" caption="Compiling Encodo.Core on the .NET Core Platform">As you can see in the screenshot, we've got one of the toughest assemblies to compile---<c>Encodo.Core</c>. After that, we'll try for running some 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.<fn> These changes will almost certainly cause builds using previous versions to break. Look for any additional platform support in an upcoming major-version release.</div> </dl> <hr> <ft>There were, of course, more minor and patch releases throughout, but those didn't introduce any major new functionality.</ft> <ft>Punchclock, our time-entry and invoicing software---and Quino "<a href="http://encyclopedia2.thefreedictionary.com/eating+one%27s+own+dogfood" title="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.">dogfood</a>" product---had been in use internally at Encodo earlier than that.</ft> <ft>E.g. splitting the monolithic <c>Encodo</c> and <c>Quino</c> 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.</ft> <ft>One of those breaking changes was to the <c>MetaBuilder</c>, 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 customizable.</ft> <ft>In the years between <b>v1</b> and <b>v2</b>, 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.</ft> <ft>That is, when users upgrade to a version with the newer APIs, they will get <span class="warning">obsolete</span> 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.</ft> <ft>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... :-)</ft> <ft>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.</ft>