Update Protocol, react please

[Fireburn]

Hi there, we've been working on an update protocol, which should assure updating goes correctly. What we've got so far is the following, feel free to give any suggestions. You have 4 days to reply here.

Update Protocol
To assure updating the LVP server goes fine without problems, we will be using an update protocol.
We want to keep the weekly updates, and we want to keep them at Sunday, so people will have some time in the weekend and can do some stuff. However, to make sure everything is welltested, and the gamemode we update to actually works, we’ve made this protocol.

So, let’s start on Friday, people are still developing, in the weekend, and will continue Saturday, they can still commit.

Now to make ourselves ready for the new version, a new branch will be created Sunday around 6.40 GMT. This branch will be created from the trunk folder, and will be used to finish the build.
So make sure all commits are done before Sunday 6.40 GMT, commits done after that will not make it into that week’s build.

After we’ve created the branch, we will compile that version, and upload that to the testserver. We then have a complete day to test the new commits, fix bugs we might find, and create a good final version of the gamemode.

After we’ve made sure the version works, we will compile it as if it was a real build, with the database details of the mainserver, and the defines set to what they would be as a real build. We also include an update to the /changelog command, and to the random announcements found in timers.pwn.
We upload this to the testserver, invite some people to play and test, especially edited things, and will see if everything works. If it does, this will be the final version of that build, and we can upload it to the mainserver.

Use SFTP to connect to the mainserver, goto the /Server/gamemodes/ folder, and rename lvp.amx to lvp.amx.YYYYMMDD, this way we can easily revert back if despite al testing something still crashes. Then upload the new build lvp.amx.

Now that the final build is ready and tested, and is waiting to be released, we can go ingame, and announce a gamemode update when we think the time is ready, for example when it isn’t very busy ingame.

We will then announce a gamemode-update in 5 minutes, we will tell people to save their stuff, start a 300-second countdown. We will keep on announcing that we will be updating the server, and that you should save your money, and be ready for a gmx.

When the countdown reaches 0, we can /rcon gmx, and wait for the server to load the new version. Sometimes the server crashes here, for some weird reasons, in that case, restart it using SSH as soon as possible, that is why there should always be a SSH capable person at an update.

After the server is updated to the new build, you check if any obvious bugs occur, and check if everything still works, which it should if it is tested properly before. If everything works, we can put the branch back into the trunk folder, and develop until a new version will be released.

Bigger updates will ofcourse require longer testing, like 2.91, which will be needed to test for over a week, but the concept stays the same, a branch, testtest, bugfix, testtest, update.

[Matthias]

Great idea, this will prevent a lot of shizzle.  d

[Jay]

I don't see the point of creating a branch for each weekly build. On average, we develop weekly builds Saturday and Sunday evenings, with around 5 changes to the gamemode. Creating a branch for five changes is a little far fetched. Fair enough I can understand things need to be tested, but why can't they be tested before the developer commits them? Most weekly changes are really minor tweaks and would require just a quick five minute test with another player. If we only commit things after they've been fully tested, trunk will remain stable.

If a circumstance occurs where a developer does make a lot of changes and they can't commit until the branch is created, which is on that Sunday, commiting lot's of changes to one revision isn't to good because it increases the chance of conflicts and makes it harder to revert changes in the future.

Additionally, over the weeks we've been most actively developing on a Sunday night, prior to the update. If we have to commit changes before 6.40 some of us may feel rushed to complete code or any important bug fixes, which may result in further bugs. It's stupid dis allowing commits before 6.40 - what if a bug is found during pre-update testing and a commit is needed before it goes live?

Use SFTP to connect to the mainserver, goto the /Server/gamemodes/ folder, and rename lvp.amx to lvp.amx.YYYYMMDD, this way we can easily revert back if despite al testing something still crashes. Then upload the new build lvp.amx.

It's pointless making a backup of the compiled version. If a problem occurs and we need the older version, what good is the amx? The full source can be reverted using tortoise svn.

[Fireburn]

I don't see the point of creating a branch for each weekly build. On average, we develop weekly builds Saturday and Sunday evenings, with around 5 changes to the gamemode. Creating a branch for five changes is a little far fetched. Fair enough I can understand things need to be tested, but why can't they be tested before the developer commits them? Most weekly changes are really minor tweaks and would require just a quick five minute test with another player. If we only commit things after they've been fully tested, trunk will remain stable.

I will explain why in the following part, I wrote this post from the last part to this, instead of doing it the usual way.

If a circumstance occurs where a developer does make a lot of changes and they can't commit until the branch is created, which is on that Sunday, commiting lot's of changes to one revision isn't to good because it increases the chance of conflicts and makes it harder to revert changes in the future.

I think you're getting it wrong, my point is that you can still commit throughout the week. However on the sunday we will get a build ready for releasing. We don't want halfly finished stuff inside the trunk anyway, so it would still be the same, with the big difference being that the update starts at 6.40, and all code before 6.40 gets in instead of all code before 22.30.

Additionally, over the weeks we've been most actively developing on a Sunday night, prior to the update. If we have to commit changes before 6.40 some of us may feel rushed to complete code or any important bug fixes, which may result in further bugs. It's stupid dis allowing commits before 6.40 - what if a bug is found during pre-update testing and a commit is needed before it goes live?

It's true that most of the stuff gets done sunday, however, if we have a properly functioning betateam, we can test it for a week, assuring there will be less bugs in live server builds. And the deadline isn't a rushing deadline, there is nothing wrong with adding a function later than the deadline, it will just be tested for a week, and will be put online the week after. I've been updating for a few months now, and there are times some weird fuckups sneak into the gamemode, which take hours to solve, resulting I am late in bed again, with creating a branch around 6.40, we will have the whole day to fix it. And about bugupdates, it's quite easy getting them into the branch, will require some copypasting, but this way reduces stress levels, because an update can be ready say 16:00, instead of 23:00.

It's pointless making a backup of the compiled version. If a problem occurs and we need the older version, what good is the amx? The full source can be reverted using tortoise svn.

We always done that. Why? Because when an update goes wrong and some way fucks everything, we need to be able to downgrade within a minute. By backing up we can be sure that can be done. You don't want an offline server while searching through all commits trying to find what possibly is wrong, or what possibly crashes the server.