You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@jonorossi, it's been you who opened the last few "Release X" issues. I'd like to suggest that we do a release at this point; the async interceptor folks appear to be eagerly awaiting it.
The remaining open issues don't strike me as particularly urgent, nor as ones that we could deal with very quickly. A few thoughts:
The main concern I'm having right now is whether we should mark even more APIs as deprecated in this next release, since we're already partly into the process. However there's no requirement to deprecate everything we want to in a single session. We can continue it in a 4.5.0 release or skip the [Obsolete] marking altogether and simply remove stuff in 5.0.0.
The DictionaryAdapter issue (Future of Castle DictionaryAdapter #394) is an example of that. We could deprecate it now & move it into a separate repo (which I've got ready on my dev machine), but we can also wait until after 4.4.0 and then start a concerted deprecation effort including DA.
Great summary of the open issues. I agree completely that we've got heaps of stuff to deprecate but it is all much lower priority than actually getting these new features out there, and as you mentioned we know we have to line up deprecations with more planning sometimes to make sure projects like Windsor have a path forward before pulling the rug from underneath them.
Yes I think it is time for a release, I was just waiting for #445 to be merged to make a release, we probably should have had this issue open earlier with that info.
@jonorossi, it's been you who opened the last few "Release X" issues. I'd like to suggest that we do a release at this point; the async interceptor folks appear to be eagerly awaiting it.
The remaining open issues don't strike me as particularly urgent, nor as ones that we could deal with very quickly. A few thoughts:
The main concern I'm having right now is whether we should mark even more APIs as deprecated in this next release, since we're already partly into the process. However there's no requirement to deprecate everything we want to in a single session. We can continue it in a 4.5.0 release or skip the
[Obsolete]
marking altogether and simply remove stuff in 5.0.0.The DictionaryAdapter issue (Future of Castle DictionaryAdapter #394) is an example of that. We could deprecate it now & move it into a separate repo (which I've got ready on my dev machine), but we can also wait until after 4.4.0 and then start a concerted deprecation effort including DA.
Issues regarding CI (CI build server platform consolidation #441, Give Lokad/ILPack a test drive to see whether we can use it to improve test coverage #431) are mostly independent from release planning and can be done anytime.
The issues dealing with logging (Contrastive behavior of NLogIntegration against NLogs #418, Future of Castle logging abstraction and adapters #408) probably require more time as we previously discussed deprecating the logging facilities, but we still need to make provisions for how Windsor will log in the future.
The issues dealing with .NET Standard 2.x (Support .NET Standard 2.0 directly #407) and System.Reflection.Emit (System.Reflection.Emit package has been delisted #374) are probably best left waiting until .NET Standard 2.1 & .NET Core 3.1 arrive, otherwise we risk adding new TFMs that we'll want to get rid of again only a few months' time.
There are some older issues, these can probably wait a little longer, too. ;-)
Thoughts?
The text was updated successfully, but these errors were encountered: