Summer holidays are over, time for a new roadmap

Programer

Active Member
Reputation
0
As many of you many have noticed, things have stalled a bit over the summer on the master branches of openrasta and openwrap. While our amazing contributors are still sending pull requests and development has continued, as the owner of the master branches I’ve not been there to maintain the new packages, as I decided to tae the summer slow and learn how to*rest*.
Now that the summer is over, I’m glad to clarify the roadmap for OpenEverything frameworks:

OpenWrap 2.0 with ReSharper support and cached remote implementation is nearly done, but a lot of features planned for 2.0 will be rescheduled for future versions. I expect a release for this in the next two weeks.
OpenRasta 2.1 work is coming along nicely, with all the bug fixes that have been suggested, and some extension points that will be needed for the work on 3.0 to start. I expect that work to be completed by the end of September. I’ll also make OpenRasta available on NuGet, although it *will* auto-install OpenWrap in your solution.We’re dropping .net 2.0 support, as it’s been out of the binaries for a while and no one has requested them back, so I’ll assume no one needs that anymore. Note that some work is going in this release that will let OpenRasta manage in-memory / caching automatically, so if your code depends on the request or response stream being seekalbe, I’d start making some changes now.
OpenRasta 2.2 will be next, and again we’ll take any additional enhancements that don’t break binary compatibility. I’d like to continue taking those changes and start doing per-feature or per-bugfix releases.
OpenRasta 3.0 is going to be where heavy rewriting is going to happen in parts of the API I don’t like, and we’ll take the luxury of redesigning and renaming / refactoring what needs to be (for example, IType et al will probably disappear and be replaced by a simpler model, the key/values binding model will be updated to provide additional information and extensibility points for those crazy people wanting a plug-in validation framework).In order to guarantee that
 
As many of you many have noticed, things have stalled a bit over the summer on the master branches of openrasta and openwrap. While our amazing contributors are still sending pull requests and development has continued, as the owner of the master branches I’ve not been there to maintain the new packages, as I decided to tae the summer slow and learn how to*rest*.
Now that the summer is over, I’m glad to clarify the roadmap for OpenEverything frameworks:

OpenWrap 2.0 with ReSharper support and cached remote implementation is nearly done, but a lot of features planned for 2.0 will be rescheduled for future versions. I expect a release for this in the next two weeks.
OpenRasta 2.1 work is coming along nicely, with all the bug fixes that have been suggested, and some extension points that will be needed for the work on 3.0 to start. I expect that work to be completed by the end of September. I’ll also make OpenRasta available on NuGet, although it *will* auto-install OpenWrap in your solution.We’re dropping .net 2.0 support, as it’s been out of the binaries for a while and no one has requested them back, so I’ll assume no one needs that anymore. Note that some work is going in this release that will let OpenRasta manage in-memory / caching automatically, so if your code depends on the request or response stream being seekalbe, I’d start making some changes now.
OpenRasta 2.2 will be next, and again we’ll take any additional enhancements that don’t break binary compatibility. I’d like to continue taking those changes and start doing per-feature or per-bugfix releases.
OpenRasta 3.0 is going to be where heavy rewriting is going to happen in parts of the API I don’t like, and we’ll take the luxury of redesigning and renaming / refactoring what needs to be (for example, IType et al will probably disappear and be replaced by a simpler model, the key/values binding model will be updated to provide additional information and extensibility points for those crazy people wanting a plug-in validation framework).In order to guarantee that
 
Back
Top