Release 6.0.0 #621
Comments
|
Really looking forward to this release. |
|
I'd like to add There's quite a lot of open issues at the moment - might be worth blasting through them and seeing if any will cause breaking changes (i,e. ideally done before bumping to 6.0.0) or if they can be handled with point releases? Maybe 🍻 over Discord sometime, rather than it being a one-person slog? 😄 |
|
Will #618 be included in this release? |
|
I'm going to have some time to look into this again next week and it would be great to the point where a beta is available (full release might be pushing it in a week!). @jonorossi do you have any more thoughts on what should be in this release? I'm still not sure how to resolve #616 and thus get #619/#622 would ideally be resolved as part of the |
|
@Jevonius thank you for still caring |
|
@jonorossi are u there man? |
|
@tasoss yes |
|
Hello! in Content Cloud we have this https://jira.sso.episerver.net/browse/CMS-23829 we would like to achieve that has dependencies on this package. are we good to do this now? if someone could review would be greatly appreciated :) |
|
I've created #630 (currently in Draft) for the |
|
Should #631 be added to the list too ? Some of the changes could be breaking (e.g. pulling functionality out into an optional NuGet package rather than having it baked in). |
|
Hi, may I ask what the "really soon" means in the update to the newest "Castle.Core" mentioned in the post from August? I'm aware that this is a free library to use but now we are really considering to switch to another IoC container supporting the newer versions of .NET and I'm used to (and familiar with) Windsor's features so this is not my preference however.... There is already the .NET 7 available but Windsor doesn't even support the .NET 6 yet ... :( Is there any light in the end of the tunnel already? |
|
I have stopped wondering anymore. |
|
Yep... looks like a dead project. |
This is exactly my situation and i totally agree with what you said . |
|
@tasoss @Kermel I not trying to sound rude, but if you want this project to continue you have to get involved, who do you expect to work on it? The status of this library isn't new, I've been saying for years that there is no maintainer for Windsor and that I'm not maintaining it. I've been trying to kick things along every now and again hoping that someone would step up. Yet another rude message on Sep 1st (not in this thread) pushed me to really step back from all this, I don't need that in my life after contributing to Castle for over a decade. When I say I need someone or a group of people to step up, I don't mean you have to formally manage anything or commit to doing things for a time period, but take some charge and decide what needs to be done. If you have no free time and your boss won't give you a couple of hours a week to help get this project you rely on back on track, then you can't expect me to contribute my free time. I'm happy to discuss how you can get involved. Apologies @Jevonius, you got me with those pull requests at a low point with this project where I just deleted the emails without even looking at them. I'll review them now. |
|
@Jevonius can you please rebase your 2 pull requests with merge conflicts and the NUnit one, then once they're merged rebase the logging one. |
I'm happy to help out with deciding what needs to be done, so we can move forward and make sure this good project does not die out. Let me know if you @jonorossi want help in this regard. We use it in all of our projects, so if this dies, we are looking a replacing it with some other code = hughe refactoring of a lot of projects. |
|
I've done a fork and removed all code related to older frameworks, so it only supports .net 7.0. The work can be seen here https://github.com/microting/Windsor I've also released a nuget package working with the latest castle.core for net 7.0 only if anyone is interested in it https://www.nuget.org/packages/Microting.Castle.Windsor/ DISCLAIMER: it's not tested on anything other than net 7.0 codebase. |
|
@jonorossi Please accept my apologies if my post offended you. I didn't mean to be rude, I'm aware that this is s free library and tha authors (You) work on it in your free time. Unfortunatelly currently I hardly manage all my duties at work (finishing a long-term project and steering work of many dev's around) so I'm afraid I can't contribute much myself. |
@Kermel I can do that. I've also added Github build actions including a nuget release part and dependabot. We internally needs to have packages up to date all the time. Our own maintained packages are getting releases multiple times pr month due to upstream dependency updates if that makes sense. |
Just trying to get some understanding here. When you say that it doesn't support .NET 6 and .NET 7 - What exactly do you mean by that?? Should it be assumed that your talking about ASP.NET 6 and ASP.NET 7 and that it refers to the facilities that provide integration points for AspNetCore? Or are there other integration points that is broken here? Using it "Raw" in .NET 6/7 doesn't seem to be an issue. Since these integrations are essentially decoupled from Windsor, you can always build those integration points your self, although granted it's not always straight forward to do so and it is ofc. really nice when IoC/DI Containers provide that for you. |
|
@renemadsen Any reason you wouldn't target .NET 6 (like has been done) rather than .NET 7 since .NET 6 is the LTS release supported until after .NET 7. I'm not saying I'm right, just trying to understand the reason. Could you highlight some of the issues supporting .NET Framework for a bit longer, again not saying it should keep doing that, just want anyone coming later to understand the reason. @renemadsen Really keen to see you contribute at least the GitHub Actions set up by itself. Any time someone complains about the build over the last few years I've asked someone to contribute the work to move to GitHub Actions like we did for Castle Core, but just crickets. You've done most the work, or maybe all the work. @Kermel No offence taken, it is more just the same cycle over and over. Everything built here is contributed by someone at some point, usually just people contributing something they want which is what makes sense. Even if you don't have time to write code for the project contributing to discussions is still valuable. |
Just because all new code I touch is getting targeted net 7.0 and getting updated targets as new .net versions are released. Just to keep all projects up to date and not having to maintain legacy code and build up a huge block of code depth. In my experince it's easier to maintain a lot of repositories if they all get small incremental updates and follow the release cycle of .net for framework updates.
Glad it's a help. At least it's covering all the tests found the in the AppVeyor |
I probably messed up more things together (writing late at night :) ).
|
While it is true that it often is easier to keep up with the newest version of .NET in general, it's not always the case, when your a library author you have to consider where your audience/"customers" is as well. If you wish for wide adoption and in turn chance to get contributors there is a balance to be struck here - which is also why you see many bigger projects targeting multiple versions of .NET. in line with what is official supported by Microsoft. |
|
@jonorossi I really really don't want to be rude or sound bad but i must reply because you said a few things.
Well if you behave like you did on @Jevonius then no one :)
No reply from anyone If you mean that my message was rude then i believe telling ppl "really soon" (but knowing that you don't believe it) or saying that you didn't see all the pull requests from @Jevonius because you deleted the emails without viewing them( come on , you can do better than that). I remember @Jevonius calling you to talk over at slack (or whatever) and discuss the issues with no reply from your part. BUT i have to admit something. I didn't know that you have already said , that you are not maintaining the project! Anyway i don't want to continue this discussion. Thank again @jonorossi for all your hard work (really). |
I understand that, but tend to lean towards we need to move forward and kind of nudging people into updating their own codebase in order for them to stay up to date. Feel free to downgrade to .net 6 or netstandad, but I'm just not going to put the work into supporting older platforms. |
That "Update to new Castle Core (coming really soon)" text was referring to the next version of Castle Core, version 5.1.0 which was released later that day on August 2nd,
No explanation to that, yes I should have done better, sorry @Jevonius. I too must have missed the request for Slack, I don't have time for that sort of immediate discussion, way too much going on in my work and personal life.
I've always tried to weigh up the pros and cons for changes to Castle libraries for all users. The problem with projects that have been around a long time is that there are a lot of features, just because one person doesn't see value in a feature doesn't mean it should be removed. There has been a number of people contribute to this project in more recent years, however the more disruptive the changes the more chance you alienate existing users and block them upgrading. If I don't have some confidence of the project not being ripped to pieces to remove everything one individual doesn't use like I had happen a few years back then the Nancy option is more likely. Good discussions, but can we get this issue back to Windsor 6.0 so we can get the changes released. The current list is in the issue description. |
|
As for the current list and the posted question "Update to Castle Core 5.1.0 or leave the minimum at 5.0.0?"
|
|
Could someone submit a pull request to bump to Castle Core 5.1.0. |
#641 including all the github actions etc. But it's for net 7 only, so old legacy code for webapi, aspnet, wfc is not tested, but it's still in the codebase if one wants to fix it. |
|
No apology needed to me, totally get dealing with projects like this can be a bit thankless at times! Plus, life often gets in the way too :) I was having a look back through at the commit history at one point, this project (+Castle as a whole) has been around for a long time, with lots of different maintainers over the years. As you point out, people generally only tend to care about the bit they need/use, so hard to get full coverage, and clarity, on what's still needed. I've rebased all the PRs that needed it, but unfortunately nearly all of them change the same line, so they're probably going to keep conflicting as each gets merged down. Oh well! I'll try and find time to have a look at #622 too - would be good to figure out what of this might be a breaking change before |
|
@Jevonius thanks
I've got them all merged except the logging one.
Sounds good. I'll add it to the list for now, we can always change it later. |
|
Really looking forward to this release too! |
|
Happy New Year to all :) |
|
Hi, as posted elsewhere I'm trying to get back into this now. Will look at #636 first, then hoping to fully understand #622 to know if it might cause breaking changes. The conditional compilation bits (#631) generally aren't breaking, so can wait for a point release; will park the rest for now. |
|
Hi there, thanks again for diving back into the project and working on this. |
@thibnes thank you so much for putting into words my own hopes and encouragements ! |
|
Is there a possibility of seeing this implemented prior to the release of .NET 8, in your opinion? |
Well, time (months) passes: now I would say: "at least before World War III is officially declared?" Aaaand no, I'm not sarcastic. I mean, there are a lot of more serious and pressing problems out there, but here it shouldn't be so complex to say a decisive word about the elephant in the room: are we at a dead-end? If so, please stop keeping us all to hope that this empasse is just a couple of PR merge far from resolution... |
|
No need to be snarky, no one is being paid to complete this work.
The silly thing is it literally is just one pull request from resolution. I've removed the milestone off #622, anyone is free to finish #636. |
What is missing in #636 so we can move on? Maybe I can help, but needs to know what is missing? |
|
Anyone to help @renemadsen ? @jonorossi or @jonorossi would you know what's missing in #636? |
|
I am currently in the process of removing the Windsor depedency in our industrial project. But before putting any more effort into that, we are discussing to put the hours into Windsor instead. We have used it for over a decade now and did contribute some years back. We would like to get involved again and if @jonorossi has some patience left, he could point me in the right direction to pick up. |
|
Just merged the last pull request for 6.0.0. Sorting out the changelog now. |
Thanks everyone that contributed. I'm keen to see some contributions to modernise Windsor. |
Castle.Facilities.Logging#636The text was updated successfully, but these errors were encountered: