Godot: A six-month development process between versions (discussion)

[ret80]

Now it is not clear how many wait for the new version. This is not good. I propose to go on a six-month development process (as Canonical Ltd (Ubuntu)). 5 months on the development and implementation of new features and 1 month for testing and fix. If something does not have time to simply tolerated in the next version.
Some will ask, and it will change and what advantages does it mean? The answer is: the developer will be able to more flexibly plan the development of the game. For example: we have started to develop the game at 2.0, and we know that in six months there will be version 2.1 with a feature we required. The developer knows whether he has time to move to a new stable version of the engine or whether it needs to implement this feature on their own or even to abandon it. All this nonsense seems at first glance, but for commercial projects with real deadlines is very important.

[akien-mga]

A time-based release schedule is pointless for a community led project such as Godot. To be able to match such expectations we'd have to dramatically change the way we work, for very little gain. Such releases always end up rushed because there are always critical bugs towards the deadline, and we end up with very bad products (and Ubuntu is not particularly a good example for bugfree time-based releases...).

Users that need a stable version can use the 2.0.x releases which are done roughly each month. If those users really need features from the 2.1 development branch, they can use the alpha and help test it, or backport the relevant patches that they need.

_Release when it's ready_, I don't see any reason to do anything else.

[SuperUserNameMan]

And also that might put too much pressure and stress on the devteam's shoulders which would be bad for their health and their mental on long term.

[ret80]

@akien-mga That's always. right there! Supported by a stable version here, too, vehemently opposed (it is quite possible that you were her opponent). But in the end it was only better. In fact, I did not see the arguments against but to the reluctance to change anything. Release when ready - very annoying because it is unknown. And the unknown is always annoying (you will see a continuation of your favorite TV series when it is ready. And when will that be? :(). The release every 6 months there will be no one to annoy because all clearly know when a new version comes out. My friend is very much opposed Godot only because he did not know when there will be one or another version. and before that there was no support for a stable version of his very upset and he refused to work with this engine. a clear date is very important psychologically. I do not think that because of the emergence of a clear release of the development of the date strongly complicated. And people will only gain.

[SuperUserNameMan]

maybe consider there will be a new release every year, and voila.

[ret80]

@SuperUserNameMan You gay man :) Development Team 6 month period does what he can. If something did not have time it is simply transferred to the next version (do not punish anyone for the developers it will not). Developers only need to say after 5 months that such and such things are carried into the next version. Plus for the team is that they will learn to plan well.

[ret80]

@SuperUserNameMan a year is too long. It sounds negative. 6 months optimally.

[akien-mga]

I did not oppose making maintenance release, actually I'm even the one doing 100% of the work to deliver those maintenance release. What I opposed back then was how you were trying to dictate what we should do _for you_, instead of what we should do for the benefit of the community.

And I very much opposed your bitching about us releasing 2.0 even though there were still "bugs". That was completely nonsensical, as 2.0 had been in development for 9 months, and you still wanted us not to release it because it was not good enough for you? And now you want us to force a 6 months schedule?

I don't think having forced release schedules of 6 months is good for the community. It may be good for Linux distributions which depend a lot on the release schedules of other upstream projects, but it's not appropriate for a single piece of software. Releases are and should stay driven by features, not by time. It's what works best for us, and we're definitely not working for you but for our community as a whole (and all unpaid to do it so far, if I may kindly remind you). And if it's not good enough for your friend, good grief. It works great for the rest of the community as far as I know.

[akien-mga]

Honestly, it's much better for us not to have a fixed release date and to release when our planned features are ready, than to have a fixed release date and not be able to deliver in time.

I work on a Linux distro with a 9 month release schedule and 100% of voluntary contributors, no paid devs, and of course we never manage to deliver on the planned date. It's just not something you can ask of people working on their free time.

[volzhs]

the developer will be able to more flexibly plan the development of the game.

I agree with this.

Release when it's ready,

I agree with this also.

It seems good if godot dev team can provide rough schedule for next release only.
That could be 3 months or an year depends on how many features or how hard to implement and test.
I can understand that rough schedule would be delayed.

[reduz]

It's generally around 6 months already, sometimes a little more, sometimes
a little less

On Thu, Jun 23, 2016 at 10:08 AM, volzhs [email protected] wrote:

the developer will be able to more flexibly plan the development of the
game.

I agree with this.

Release when it's ready,

I agree with this also.

It seems good if godot dev team can provide _rough schedule_ for next
release only.
That could be 3 months or an year depends on how many features or how hard
to implement and test.
I can understand that rough schedule would be delayed.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/5371#issuecomment-228044071,
or mute the thread
https://github.com/notifications/unsubscribe/AF-Z20ac0YfpK0g5Q7Zay5Mcmdv3Gsq7ks5qOoU-gaJpZM4I8pnI
.

[volzhs]

@reduz yes. it is.
but I think @ret80 wants godot dev team announce release date or milestone.

[reduz]

It's either announcing content or release date, but not both :P. Right now
we announce content
On Jun 23, 2016 10:17, "volzhs" [email protected] wrote:

@reduz https://github.com/reduz yes. it is.
but I think @ret80 https://github.com/ret80 wants godot dev team
announce release date or milestone.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/5371#issuecomment-228046302,
or mute the thread
https://github.com/notifications/unsubscribe/AF-Z2wykJ7jZ3Sd8x8mw9szcy0EVV6sgks5qOodngaJpZM4I8pnI
.

[akien-mga]

but I think @ret80 wants godot dev team announce release date or milestone.

Well once the next milestone has been discussed after a release, we could indeed announce what we have in mind on the blog, with a rough estimate of a release month/season.

Of course it won't be fully accurate, as after 2.0 we would likely have announced a release around May/June with only the Asset Library + the new EditorPlugins, but in the end 2.1 ends up being packed with a ton more features, and will likely get stable in July/August. Still, communicating more with the community is always good, and we can post newer announcements when the release date starts being easier to estimate :)

[akien-mga]

BTW we already explained our position in a blog post after the 2.0 release: http://godotengine.org/article/updates-on-the-release-cycle-and-godot-2-0-1

SHORTER RELEASE CYCLE

Stable releases will happen more often. Release early, release often is a proven philosophy that we all affectionate and we think that it will be beneficial to Godot.

The long wait for Godot 2.0 was actually mostly due to breaking the compatibility with 1.1 (especially for the new TSCN/TRES format). We wanted to make it a big release so that the inconvenience of losing compatibility with 1.1 would be compensated by great new features.

On the other hand, we do not give an ETA for the future releases. In a community-driven project such as ours, it very much depends on the availability of the contributors, and we will then release when it's ready. There has however been some good progress on the main features that we would like to release in 2.1 (not all those of the "2.1" roadmap though, we will split it in several sub-releases in the 2.x branch), mainly the new plugins API and addons sharing platform.

[ret80]

I am well aware that the project is being done in their free time, and that people who are doing it, do not make money on it. But this is not as not applicable to planning. I emphasize that if someone is that it does not have time, it's just moved to a different version. What would release version every 6 months will need to plan for a smaller features on release.
Yes, I want to know the release date. And this year and next. I wish that it were predictable and not all at once. Recently, in version 2.1 has got a couple of fixes (thanks @reduz ). However, I expected them to 2.0.x but it turned out that they were in 2.1. And now I do not know if I wait for version 2.1 or 2.0 release to all.
I perfectly understand you, I've changed jobs a c ++ programmer testing engineer (it happened) and began to study the development of small games in their spare time. And happily ruined his schedule for the production of the game is already 1.5 times for various reasons have arisen. Furthermore. When I worked as a programmer and made the game too, we successfully have failed deadlines games release. But this does not mean that the terms should not be at all.

[akien-mga]

Recently, in version 2.1 has got a couple of fixes (thanks @reduz ). However, I expected them to 2.0.x but it turned out that they were in 2.1. And now I do not know if I wait for version 2.1 or 2.0 release to all.

Well that's precisely the point. If we were doing time-based releases, the bugfixing period would only focus on fixing release critical bugs to ensure that we don't have a too buggy release. So the bug fixing would mostly handle bugs introduced during the development phase, but not older bugs that had somehow lacked attention up to now.

With our current feature-based release schedule, now that we're considering that we are feature-ready, we can spend all the time we feel appropriate to go back in the huge backlog of issues and fix as many bugs as possible, whether critical for the 2.1 features or older. That's precisely thanks to this loose schedule that you bug was fixed. Having time-based releases wouldn't have gotten it fixed in 2.0, and probably not in 2.1 either.

[volzhs]

Of course it won't be fully accurate, as after 2.0 we would likely have announced a release around May/June with only the Asset Library + the new EditorPlugins, but in the end 2.1 ends up being packed with a ton more features, and will likely get stable in July/August. Still, communicating more with the community is always good, and we can post newer announcements when the release date starts being easier to estimate :)

Personally, I think that's enough and I'm really satisfied with it.

I agree with @akien-mga @reduz in some points.
Some of another engines, they just piled up a lot of issue those not fixed for a long time, because of release date and new features.
I really hate this. It's just buggy engine.
And, they have not released on time either and it's buggy :(

And I think, godot has really fast pace.
I feel like I can't catch up godot changes if I've not check every notification on github. :+1:

[Ace-Dragon]

I think we shouldn't be too strict about dates when it comes to releases. The Blender developers for instance will delay a release by up to several weeks if that is what it takes to get the bug count down to an acceptable level (which includes fixing as many crashes and regressions as possible).

At most, it might be acceptable to move a few targets to later release dates if they are taking far longer than anticipated to complete (so that either the release can come sooner or more time can be spent on fixing issues).

[ret80]

@volzhs If I understand you correctly that you're talking about that Godot errors are corrected very quickly compared to other engines? But it is not so! For example, even in the version 2.0 release has a problem with retaining only that the changes in the scene. And it's still not fixed. So this is a bad argument.

[reduz]

Most bugs are fixed quickly, of course bugs that affect a very small amount
of users generally take longer, but if you remind us that you need it
fixed, the bug will get fixed sooner

[SuperUserNameMan]

@ret80 : "you gay man" :P
could you please provide a link to the issue you are talking about ?

[ret80]

@SuperUserNameMan I wanted to say that you are funny. Did not work out :(

[ret80]

sorry :)

[SuperUserNameMan]

no problem ;) it was funny anyway because I knew it was a translation error.

But seriously, I'd be curious to know what issue your were talking about here :

But it is not so! For example, even in the version 2.0 release has a problem with retaining only that the changes in the scene. And it's still not fixed. So this is a bad argument.

[ret80]

@SuperUserNameMan
windows 7: I sometimes use a USB flash drive on which the Godot and the project. very often there are situations when the scene or script is not saved. next to the old file, a temporary file with the latest changes. You have to delete a file or script to rename the scenes and temporary.
mac os: after making changes to the stage and start the project carried out the project without changes. but on stage there is no indication that it is not saved. after the forced saving everything works fine

[reduz]

@ret80 regarding the windows 7 files not being saved, and a temporary file next to them, this means that the file is locked and it can't be accessed, likely something is using it. This can't be fixed as it's a windows limitation, but the version in HEAD at least will show a warning next time this happens.

[vnen]

Sorry in advance for the long rant, but I have to say this.

---

If I understand you correctly that you're talking about that Godot errors are corrected very quickly compared to other engines? But it is not so!

I want to know which are such engines that have bugs fixed quicker than Godot. Considering the amount of resources Godot have (which is the amount of people working often to fix bugs and add features), I'd say things get fixed very quickly. There might be some longstanding bugs, but those remain open because they don't happen often.

Also, amount of bugs fixed and timed releases are completely unrelated topics. I'd even say that if we tried to follow a schedule there would be many more bugs without a fix.

@ret80, you have all the right to open issues about bugs and feature requests. We want to fix bugs and to do so we need reports. But you are a user of a free engine, that does not make you a customer. Godot's license clearly states: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED[...]". For someone who don't have any presence in the pull requests (not even as comments) and is not familiar with the engine development, you are demanding too much.

We have documents, Trello board, GitHub milestones, and a lot of discussion on IRC. I'm able to follow closely when a release will be made and whether it'll delay or not. If you follow Facebook or Twitter channels you can see announcement of new features. If you want to say that "we're doing it wrong" (even when it works out for pretty much everybody else) you should come and get more involved with the development process of Godot. It's easy to say that "it should be done that way" when you're not the one doing it.

[volzhs]

@ret80 Hm. so... I guess 6 months release would cause more buggy godot release as you commented.
for me, personally, godot implements feature fast and fixes bug fast also.
(I'm not native english guy, I'm not sure that I make myself clear)

Anyway, I agree with some point of your suggestion, information of next release date. (though it's rough or delayed)

[ret80]

@vnen
en: we are now discussing how to make the Godot better or what you are to me, not what should not?
ru: мы сейчас обсуждаем как сделать Godot лучше или то что вы мне не чего не должны?

[volzhs]

@ret80 Yes, all we are and want better Godot. :)
It's discussion.
So all of us just say their own opinion. easy...

Everybody has different interests, priorities and thoughts.
We can make better Godot when we discuss, share, report, PR or etc.

[ret80]

@reduz - maybe you're right. I checked it out somewhere else. if it will play back the head of a bug

[vnen]

Point is we are getting frequent releases (2.0.3 was released little more than a month ago). And we are trying to fix the most bugs as possible. But we don't have a team devoted to bug fix.

So, I just stated my opinion and I think that forcing a timetable for a project so big with few people actually coding (and none of them full time) would do more harm than good.

[volzhs]

@vnen Yeah. I should make money with Godot engine and donate.

[ret80]

@vnen - it is quite another matter :) I understand your opinion.

[ret80]

The release date is needed - it's a fact!
How it can be obtained:
1 Discuss and about to set out to walk from the calculations.
Plus - We get as much time as we need and everyone is happy.
Minus - Most likely payment will not be correct. This upset the community. and if much mistaken the upset much :( not who does not want

2 Take 6 months and issue releases.
Plus - There is a exact date, and everyone knows that this day (+/- a couple of weeks at most) will release. everyone is happy.
Minus - The release is likely to be incomplete (not guess with the amount of features, corrected bugs or something like that). Community saddened but not as much as in the first paragraph because of the new features, there are a promised date.

If you have your options are offered.

[reduz]

nope, no release date, sorry. It will happen when it happens, and when we
feel it's ready

On Thu, Jun 23, 2016 at 4:50 PM, ret80 [email protected] wrote:

The release date is needed - it's a fact!
How it can be obtained:
1. Discuss and about to set out to walk from the calculations.
- We get as much time as we need and everyone is happy.
- Most likely payment will not be correct. This upset the community.
and if much mistaken the upset much :( not who does not want
- Take 6 months and issue releases.
- There is a exact date, and everyone knows that this day (+/- a
couple of weeks at most) will release. everyone is happy.
- The release is likely to be incomplete (not guess with the amount of
features, corrected bugs or something like that). Community saddened but
not as much as in the first paragraph because of the new features, there
are a promised date.

If you have your options are offered.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/5371#issuecomment-228163466,
or mute the thread
https://github.com/notifications/unsubscribe/AF-Z2yj9iEtgH3mLnjoKedg48MaQCelSks5qOuNogaJpZM4I8pnI
.

[ret80]

sorrow

[SuperUserNameMan]

Okay. I have a great news.
I've just read Nostradamus' book, the wholly bible and the Mayan calendar.
After some calculations and analysis, I came to the conclusion that we should get a new major release almost every 6 months and a bugfix release almost every months, all of that after the end of the world that occurred back in 2012 and before the next judgment day that will occur after the Nibiru planet collided with Earth.

[ret80]

@SuperUserNameMan - why are you so critical of the term in 6 months? this term I propose just to fix your work assignment and the next version. you do not need to change the pace of work or something like that!

[Ace-Dragon]

I still would rather have a stable release where everything just works rather than a more frequent release cycle that has lots of new features, but also lots of bugs and regressions to go with it.

I think part of the issue is the culture of some of the engines Godot is attracting users from, a lot of Unity users for instance are perfectly fine with buggy software as long as they can just work around the bugs themselves (because they see new features as something of utmost importance). For them at least, having fewer, but very stable and issue-free releases is a new concept that they have to get used to. I do ask, wouldn't it be better to have an engine that just works rather than one with a massive feature list, but at the cost of half of them not working well?

I don't think in the slightest that Godot should adopt Unity's development model and bring all of its problems as well, that's not to mention Unity Tech's decision to simply ax release deadlines altogether because of the mountain of issues that plagued it in the last year.

[SuperUserNameMan]

@ret80 :
It's not that I am critical. It is just that 6 months is almost the natural rhythm of Godot development. So I find that funny.

Personally I don't really care whether it is _officially_ 6 months with an optional delay extension, or _unofficially_ almost 6 months.

If I really need a feature that is not yet available in an official release, I will just compile Godot myself (or download a version compiled by @Calinou ).

For having used Godot from version 1.0pre to 1.1, and used alpha, beta and release candidate, I know that the biggest and most annoying bugs will be fixed quickly, and that it should be a matter of weeks. (and that I could help by putting my hands into the source code if I'm brave ennough)

So, if you really need a feature not available in 2.0.x that is already available in 2.1alpha, I think you could already use 2.1alpha and make your project evolve at the same time than 2.1alpha,beta,rc1,etc.

[ret80]

stop each other put the likes. I have one and there is so much :(

[Ace-Dragon]

For the latest issue fixes, I can now recommend the daily builds of Godot 2.1 alpha like what is being done here
http://www.purpleorangegames.com/godot/

At this point, the builds are pretty stable and relatively free of issues (save for some niggles with the 3D import).

[ret80]

@SuperUserNameMan - I have long been using Godot. and I tried the model you're talking about. it is a bad option.
evangelist support stable version, too, was me. and then I @reduz also categorically opposed and offered me what you're proposing right now. so perhaps I have a slight deja vu (https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%B6%D0%B0%D0%B2%D1%8E). the reason for me to use your proposal is not stable version sounds funny.
PS.
I hope the translator will translate all good :)

[SuperUserNameMan]

I hope the translator will translate all good :)

@ret80 : To be honest, I just hope Obama and Putin don't use this translator to talk to each other.

[akien-mga]

I believe this issue has served its purpose, so closing.