Pissed off with springlobby always updated before repository

[The_Uber_Noob]

I am getting really annoyed with the fact that springlobby server is often upgraded to the new version of spring engine before the new client spring engine is availlable in the Linux repositories. This means Linux users systematically loose a day during which they just can't play as their version of spring is incompatible with the one used by springlobby server. Would it be too much to ask to upload new spring version to the repositories BEFORE upgrading springlobby server?

[gajop]

aww
also:
1) not a "springlobby" server, it's the spring server
2) it's up to the distribution spring packagers to update spring regularly, not the spring server maintainers
3) a linux static binary is in the process of being made, and it should alleviate most issues with versions

[The_Uber_Noob]

Thanks gajop.
Sorry for the language."pissed off" was a bit over the top.

Awaiting the static binary, can it be requested that the spring server maintainers update only after the distribution spring packagers have posted to the repositories? There must be hundreds of Linux players like me who are banned from playing a day or two at each engine upgrade.

[gajop]

It's non-trivial to do that, for a couple of reasons:
1) It's hard to track each distro, some may pull it early, which would then cause problems due to having a "newer" version.
2) Some games (ZK f.e) are notorious for using a special version on their games regardless of the "current" version.
Suggest you just wait for the static binary.

[koshi]

I did build the 91 packages for ubuntu on the day it was released. They've been sitting at https://launchpad.net/~spring/+archive/staging ever since. Feel free to be pissed of at whoever set 91 live on the main server for not coordinating with anyone who could copy those packages over.

[phillipsjk]

aww
also:
1) not a "springlobby" server, it's the spring server
2) it's up to the distribution spring packagers to update spring regularly, not the spring server maintainers
3) a linux static binary is in the process of being made, and it should alleviate most issues with versions

This may be a problem for Debian users.

To avoid breakage, people are advised to avoid installing random static binaries from the Internet.
However, Debian stable freezes pakages for 2 years or more (bug-fixes are allowed, but not feature creep).

Is there any hope for a protocol version distinct from the engine version?
I am guessing "no" if you "can micro to make a unit dodge a shell".

[SinbadEV]

Yeah the "integrity" of the simulation is maintained by each system running an identical version of the simulation... there are other ways to prevent cheating but we aren't using them.

[Silentwings]

To avoid breakage, people are advised to avoid installing random static binaries from the Internet.

Anyone with that attitude can & should learn to compile for themselves.

Is there any hope for a protocol version distinct from the engine version?

No - Spring relies on having a large section of essentially identical "synced" code running on all clients simultaneously. In the past the minor version number of releases were used to indicate when only unsynced code had changed, but that is rarely used now since its no longer an appropriate model for how Spring is developed; in practice these days all new Spring versions feature changes in synced code.

[PicassoCT]

Yo, i dig only updates that are bleeding edge, the server probably never heard of them

[phillipsjk]

To avoid breakage, people are advised to avoid installing random static binaries from the Internet.

Anyone with that attitude can & should learn to compile for themselves.

One of the primary advantages of Debian is its central repository with thousands of software packages. If you're coming to Debian from another operating system, you might be used to installing software that you find on random websites. On Debian installing software from random websites is a bad habit. It's always better to use software from the official Debian repositories if at all possible. The packages in the Debian repositories are known to work well and install properly. Only using software from the Debian repositories is also much safer than installing from random websites which could bundle malware and other security risks.

- Advice For New Users On Not Breaking Their Debian System

This advice is targeted at new users. It is good that the Debian install guide mentions checkinstall. I have been using Debian for over 12 years and have still not figured it out (never saw such straight-forward instructions on using it). Edit2: Advice to use the Ubuntu repositories is bad, that results in a "frankendebian".

Edit: Further down in the same page:

Don't suffer from Shiny New Stuff Syndrome

The reason that Debian Stable is so reliable is because software is extensively tested and bug-fixed before being included. This means that the most recent version of software is often not available in the Stable repositories. But it doesn't mean that the software is too old to be useful!

Debian has a "no new features" policy for security updates.

[Silentwings]

They can climb on their high horse all they like, it's not happening for Spring.

[phillipsjk]

Well, the user always has the option to compile stuff on their own, as you have mentioned. For things like servers, those policies are very pragmatic. I myself can sometimes take more than 6 months to configure my machines, so I actually like the slower release cycle.

[knorke]

Don't suffer from Shiny New Stuff Syndrome
[...]
This means that the most recent version of software is often not available in the Stable repositories. But it doesn't mean that the software is too old to be useful!

This seems more aimed towards "user software." It does not hurt to use a slightly older version of an office program, a music player or similiar.
For an online game it is different: if you do do not use the same version as everyone else then you can basically not play. (Which means the software is indeed too old to be useful)
Maybe slightly related: http://springrts.com/wiki/EngineVersion.

[hoijui]

if stability and security is important to you, you will not care whether it is an office suite or a game that takes down your system, or spies on you or whatever. obviously, the solution is to not play "bleeding edge" games on a system you want to have save and secure. use an other system, a dual boot, a virtual OS or whatever makes sense.

[abma]

since a while we have static builds of spring for linux (32 & 64 bit). this shouldn't be an big issue any more, just download the needed version of spring and run it:

http://springrts.com/dl/buildbot/default/master/

or use pr-downloader or a lobby which can do this automaticly.

this is a two year old thread -> locked.