That is what i’d like to do. Just haven’t had the time to refactor the code on the home page to do that.
Was also considering maybe pulling posts here from Discourse as news posts.
Anything other than old Wordpress blog junk.
That is what i’d like to do. Just haven’t had the time to refactor the code on the home page to do that.
Was also considering maybe pulling posts here from Discourse as news posts.
Anything other than old Wordpress blog junk.
Hi!
I’m pretty new to MonoGame, and it looks awesome so far. Well done!
I’m quite impressed by the amount of issues included in the 3.7 release. I wonder whether releases are too big though. I’ve noticed it takes 1-1.5 years to release a minor version. Would it make sense to release more often? I know that we can work from the develop branch, but having official releases is usually helpful, and I feel like making them more often would be a good thing, even if they are smaller of course.
Just noticed that there is an update, will definitely check!
Please put this in HEADLINE page so that others will know monogame is still alive and kicking
Thanks a lot guys, I really appreciate your work!
Hi @srodrigoDev.
I agree… it would be better to release more often. This has been our goal for a few years now… we just haven’t been able to meet it.
Mostly the issue is not knowing if the develop branch is stable enough to replace the current stable release. In theory it should be… but 99% of the testing is Windows PC builds and very few people test the mobile, UWP, or Mac/Linux backends.
We are making that better in a few ways.
First by focusing on getting more automated testing into the build servers and run those tests on more platforms.
This is hard to do right… but we’re trying to push that forward little by little.
Second we are starting to push out development builds periodically on NuGet which tells us how many people actually at least tried using that develop build for a particular platform. Like i know now that 68 people used the iOS version of MonoGame 3.7.0.1681-develop … knowing that gives us confidence that it isn’t completely untested.
Last and most important i am having to learn not to care so much. If MG is buggy when we release it isn’t my personal fault. It is an open source project and how good it is or isn’t is a reflection more on the community than me personally. Worst case if it is really buggy there are a dozen older versions on NuGet or we can push a fix in a minor release. What we cannot do any longer is wait to ship.
Thanks @Tom, that makes a lot of sense. I had the feeling that I didn’t have the context needed behind the current approach. And I think, given the small team behind MonoGame, it’s a very reasonable approach, specially for less used platforms, as you mentioned.
I agree that increasing the automated test coverage could definitely help. In any case, I wouldn’t be extremely concern about breaking changes. The reason is that, with smaller releases, it’s easier to feel more confident about the stability of the development branch, and also it’s probably easier to manually test when the automated tests suite can’t help, as there are far less things to test. Smaller releases are also a good “check point” in case there is something broken, as users could revert back without loosing much functionality.
I also agree with getting the community more involved. As an idea, I wonder if releasing a release candidate version could help? I’m not even sure if this is done already, as I landed here a few weeks ago. But maybe that way it would help both getting users more involved in testing (people usually jump into new oficial versions more than particular commits on the current development branch), and also being more confident with releasing more often.
Also, it’s important to remind users to report bugs, instead of trying to fix them ourselves. I remember reading something about this about MonoGame somewhere…