scheduled releases?

[abma]

What about scheduled releases?

every three months we make a rc1, and a week later rc2, (... as long it is "stable") and then stable release which will be set live after 3 days?

i know, we are doing this in our spare-time / blablabla... but imo this could simplify a few things. also our plan already was to have the develop branch in a quiet stable state that could be released as it is.

(edited for clarifying)

[zerver]

I suggest we have a scheduled test game every month and release the tested version if the test game didn't indicate too many problems.

[cleanrock]

+1 for scheduled test games

[abma]

(moved to engine as it affects much more people)

my suggestion is to make a release every 3 months (at least we should try so)

with multiversion support of most lobbies mostly always the current development version is tested. With a fixed schedule it should be easier for others to know when they have to test. Atm nobody really knows when a release is planned.

scheduled test games are imo off-topic in this thread.

[smoth]

If you stuck strictly to that schedule I predict disaster

[abma]

If you stuck strictly to that schedule I predict disaster

why? and what is your definition of "strictly"? other opensource projects have a scheduled release plan so why can't we do that, too?

i'm pretty sure we can do this, else i wouldn't suggest it.

[AF]

Because a lot of projects define their dependency on spring as "the latest version of the engine" or the "single version installed", not "the latest version verified to work"

[abma]

Because a lot of projects define their dependency on spring as "the latest version of the engine" or the "single version installed", not "the latest version verified to work"

then a schedule released would perfect for them. they can plan, when they have to release an upgrade of their game/map/whatever to retain compatibility to "current" version.

unmaintained projects will very likely "break", but they'll break reagardingless if releases are on a schedule or not.

fixes/new features to the engine are only "applied" when a release made. releasing >6 months like it is atm is way to long between releases.

[CarRepairer]

Because a lot of projects define their dependency on spring as "the latest version of the engine" or the "single version installed", not "the latest version verified to work"

There was a discussion (don't remember if chat or thread) about a proposed modinfo tag to define the engine version. Would solve this problem, once lobby clients account for it.

[smoth]

Because a lot of projects define their dependency on spring as "the latest version of the engine" or the "single version installed", not "the latest version verified to work"

then a schedule released would perfect for them. they can plan, when they have to release an upgrade of their game/map/whatever to retain compatibility to "current" version.

unmaintained projects will very likely "break", but they'll break reagardingless if releases are on a schedule or not.

fixes/new features to the engine are only "applied" when a release made. releasing >6 months like it is atm is way to long between releases.

Because sometimes the engine isn't ready to be released? Every 3 months as a hard deadline even in the corporate world results in release day issues. The difference is usually the team is there in case there are issues. This is a volunteer project meaning if there is an issue it could be another 3 month cycle before it is fixed. There are several people working on several areas of the code at one time. Setting hard time limits like this can result in shoddy releases.. such as 93.1

It hurts the community. We lose players.

[abma]

@smoth:
you didn't answer my question. whats your definition of "hard limit"? you are assuming stuff you don't know and are just bawing atm, thats annoying and demotivating. with your reasons we never would have make a release. if you don't understand... please ask!

"stable" means, it IS ready. a non-working engine can't be released.

making very few releases distracts engine developers, its frustrating for them because its unknown when their work gets released. having no engine developers is much worse for community.

atm it is like this: devs implement new stuff, then after some time it is noticed that last release was a long time ago. then code is fixed, and when code is fixed it is released. only difference between schedule and no schedule would be is that the time between implementing fixed stuff and stabilizing is fixed. and i'm asking what time it should be / what is reasonable for it.

i'm just assuming now we will make releases on a schedule. whats a reasonable time? how often to make a release? (if possible, with reasons, why this time/schedule)

[smoth]

every three months we make a rc1, and a week later rc2, (... as long it is "stable") and then stable release which will be set live after 3 days

3 weeks
rc1
1 week
rc2
is it "stable?"

Release.

So essentially 1 month 1 week and release.

you are assuming stuff you don't know and are just bawing atm

RUDE

"stable" means, it IS ready. a non-working engine can't be released.

IS ready is still too ambiguous. Stable as you define it just means doesn't crash not does it break key elements that games are still stuck depending on the engine to handle.

making very few releases distracts engine developers, its frustrating for them because its unknown when their work gets released. having no engine developers is much worse for community.

So is having their game broken, the community has seen a few mass exodus of players when the pathing was very bugged. They went on to play something else.

As a content dev, IDGAF, it doesn't effect me as I have no project out there. if you guys break some key code because of your 1.25 month release cycle it would be very frustrating for them and someone would have to hurry to push out a fix of their code. I have NO dog in this fight, my shit doesn't care if people can play it because it isn't out. If I did though, that would be a MAJOR concern for me.

atm it is like this: devs implement new stuff, then after some time it is noticed that last release was a long time ago. then code is fixed, and when code is fixed it is released. only difference between schedule and no schedule would be is that the time between implementing fixed stuff and stabilizing is fixed. and i'm asking what time it should be / what is reasonable for it.

I am saying such an arbitrary deadline could lead to catastrophy. You need to consider as you are going, check with your devs to see if they have a timeline(which they probably will over/under shoot). That or ask them to set reasonable and attainable goals for the dev cycles. Considering the willie-nillie nature of the things that are addressed I suspect asking them to lock things down and only work on one thing could stifle them. It could also stop them from fixing things as they find them(kloot and jk do this a lot).

i'm just assuming now we will make releases on a schedule. whats a reasonable time? how often to make a release? (if possible, with reasons, why this time/schedule)

I am saying 1.25 months will probably end in a catastrophe eventually. I think you should consider looking at the phase based on what each developer is working on. Consulting them, posting calendars on the site etc. Just saying do this for this period of time is no good. Programming cannot really work that well in a RIGID time schedule like your first post. Some things take longer than others.

So when I say rigid, i am saying your initial proposal of 1.25 month is inadequate and doesn't consider the time that the developers may need to work on something. It is RIGID because 1.25 months maybe too long, or too short. I am saying, 2 rcs isn't always enough, because people are going in and changing parts along with what was "already done." Unlike a real life project, this is something the guys enjoy, so once their work is done they are going through and doing other shit. This isn't a scrum sprint.

[xXx]

Smoth,

Reread abma's statement. It's not 3 weeks, plus 1 week, plus 3 days. It's 3 months, plus 1 week, plus 3 days. So instead of 1.25 months between releases, it's 3.25 months between releases.

every three months we make a rc1, and a week later rc2, (... as long it is "stable") and then stable release which will be set live after 3 days

3 weeks
rc1
1 week
rc2
is it "stable?"

Release.

So essentially 1 month 1 week and release.

[Forboding Angel]

To reiterate what abma was saying @ smoth... he is basically saying have a ready to release spring every 3 months.

@abma what smoth is replying is that 3 months is a tough deadline to hit even for big corporations.

@ both of you, I really would like this sort of schedule, but you developers would need to do a little more communication and streamlining to make sure that no one gets left behind or swamped.

Edit, ninjad. Smoth, please don't escalate. You are taking abma out of context and you're making an issue where there is none because you aren't understanding what he is trying to say.

[smoth]

To reiterate what abma was saying @ smoth... he is basically saying have a ready to release spring every 3 months.

yeah, release early release often etc.. it has caused many issues in the past.

@ both of you, I really would like this sort of schedule, but you developers would need to do a little more communication and streamlining to make sure that no one gets left behind or swamped.

That is a major concern but so far there has been a bad track record of game breaking releases. I am not sure it is fair to expect that to change. Things get overlooked etc.

@abma what smoth is replying is that 3 months is a tough deadline to hit even for big corporations.

Edit, ninjad. Smoth, please don't escalate. You are taking abma out of context and you're making an issue where there is none because you aren't understanding what he is trying to say.

In case I am some how being unclear. I think it is bad to push a RELEASE just because it is 'stable' based on the definition he has put forward. Again, forb, I don't have a dog in the fight, I am more to the point trying to speak out over concerns. I don't think abma was being fair to me in his earlier statement.

Smoth,

Reread abma's statement. It's not 3 weeks, plus 1 week, plus 3 days. It's 3 months, plus 1 week, plus 3 days. So instead of 1.25 months between releases, it's 3.25 months between releases.

3 months 3 weeks. Doesn't matter was just pointing out that I think a static time range decided arbitrarily and held rigidly will cause issue. 3.25 around here passes fast but for a player, if the engine is broken for 2 hours that is too long these days. This disposable game generation doesn't have the patience to stick around for a game to be broken for more than a week.

[gajop]

I don't mind the idea of scheduled releases, but here are two question:
When do you stop adding new features (or other major changes) and decide it's time to fix the bugs?
Could this slow down the progress?

[dansan]

From other OSS projects it's known, that the only "rigid" schedule is the one in which new features are added, and the stabilization time after a feature freeze is rather flexible.

I don't see the problem with multi-version engine support. Games can stay with the engine version that works for them until they have been adapted to newer versions. If proper multi-version engine support in all major lobbies is a precondition for this plan - just state so.

[smoth]

that would be a good point dan

[Funkencool]

I think this would be great. It would fit nicely with the move towards multi-engine lobbies. A perfect example is ZK skipping spring 94 with relative ease. The biggest hang up, I know of, was linux players not having static builds of spring 91 but that would no longer be valid anyway.

When I know a new feature is in the works, it would also be awesome have an idea for a personal deadline to implement said feature game side.

[FLOZi]

yeah, release early release often etc.. it has caused many issues in the past.

Yes... because it never actually happened.

Scheduled releases makes sense IFF all lobbies support on-the-fly engine downloads/hosting AND games can indicate engine support to those lobbies.