15 Apr 2019
Today I’m really pleased to announce that I’ve pushed version 4.0.62-alpha to Nuget. This marks a pretty big step in that most of the interfaces provided by Caliburn.Micro have been migrated to an async implementation. This includes crucial classes for view model lifecycle such as:
IActivateIDeactiveIConductorIGuardClose
Obviously a change like thise can seem like a large breaking change, however the nature of these changes make the fixes quite small.
I’ve started documenting the changes and migration path to 4.0.0 which I encourage you all to read.
If you want to use more update to date builds as they become available then the CI feed for Caliburn.Micro.Core and Caliburn.Micro will be updated on every successful master build.
Most of the changes coming before the beta will be smaller ones, bug fixes and any missing async implementations.
05 Dec 2018
Progress is well under way for 4.0.0 and I’m closing in on producing the next alpha. This will contain a majority of the breaking changes regarding moving to an “async first” model across the Screen and Conductor classes.
In order to quickly gather feeback from the community I’ve set up a CI (Continuous Integration) pipline using Azure Pipelines and MyGet. This pipeline will publish the packages from any successful build on the master branch to this feed.
The CI feed is available for Caliburn.Micro.Core and Caliburn.Micro.
Thanks to MyGet for providing the public feed.
For anyone who’s interested the pipeline itself is defined in the repository at azure-pipeline.yml. Personally I’ve a big fan of defining as much as we can in declarative fashion including infrastructure and process.
Over time I’ll be looking to expand on this to do things such as build / check the samples and create new template packages.
23 Jan 2018
Today I’m pleased to say I’ve published the first preview of 4.0.0. The version of this pre-relase is 4.0.0-alpha.1.
This release is earlier that I’d normally I’d like as it’s not yet feature complete, however a lot of people are asking for versions that support .NET Standard. Given this I’ve pushed out this release early, and after a bit of thought I suspect it will be a good thing in the long run.
The major “theme” for 4.0.0 is “async”, moving most major interfaces such as IActivate, IDeactivate, IGuardClose etc to async implementations. Naturally this will involve a lot of breaking changes as I move forward. Potentially rolling out early alpha releases at various steps can lessen the blow for people wanting to be on the bleeding edge. The first interface up for changes is IEventAggregator and is included in this release.
I’ve started documenting the changes and migration path to 4.0.0 which I encourage you all to read.
If you’re interested in what’s in the pipeline for 4.0.0 you can view the project on GitHub as well as the associated milestone.
If you do upgrade and run into any issues please log them quickly (with a reproduction if possible) and I’ll see what I can do.
17 Sep 2017
A small house keeping release in part to get ready for Windows Template Studio work.
Included are the following:
- #443 Remove a rogue dependency on System.Web that was accidentally included.
- #462 WPF Window Manager won’t override a Window’s Title if it’s been set. Thanks @tziemek.
- #466 Add a
Set implementation to `PropertyChangedBase.
- #475 Platform provider methods are now virtual.
18 Jun 2017
I’m pleased to say that development on Caliburn.Micro 4.0.0 has started on the branch dev/4.0.0. One of the first things I’ve done is transition the whole solution across to Visual Studio 2017, .NET Standard and making use of multi-targeting.
As it stands right now Caliburn.Micro.Core which was previously a PCL will now target .NET Standard 1.0 which gives a great range of supported platforms. Caliburn.Micro.Xamarin.Forms targets the .NET Standard 1.6.
I’ve also taken advantage of the new multi-targeting approach allowed in Visual Studio 2017. Previously for all the Caliburn.Micro.Platform projects I had all the source in one folder along with around six to eight project files. Each project simply included or excluded the files it needed with compiler directives if it needed to exlude only a little code.
Switching to multi-targeting doesn’t really change this approach except we can shift from all those project files to simply one. Along with wild card inclusions platform specific code only needs to be dropped in the right folder for it to be used correctly.
There’s a lot of work to be done before I consider doing a release but if you’re looking to try it out or see how a project that targets a lot of platforms looks when making this change feel free to check out the code.