aliens

Author Topic: OpenXcom 1.1  (Read 26330 times)

Offline Warboy1982

  • Administrator
  • Commander
  • *****
  • Posts: 2338
  • Developer
    • View Profile
    • Email
Re: OpenXcom 1.1
« Reply #30 on: February 12, 2015, 11:42:31 pm »
i'm kinda with volutar on this one... while supsuper does make a good point about the fans demanding tftd, i think we might see more "benefit" from stabilizing the code for another milestone build, if for no other reason than to try and migrate people away from the year and a half old build. maybe we could alter our approach a little too? like have a "stable" branch that receives critical bug fixes, and continue working on the nightly branch until we reach another "milestone". the fans may be disappointed that there's no tftd, but an update to the "standard" could make things a lot better for everyone, modders and bughunters inclusive. i'll grant you we don't have a suitable candidate at this exact moment but it's still something we could work towards?

Offline ivandogovich

  • Commander
  • *****
  • Posts: 2376
  • X-Com Afficionado
    • View Profile
    • Ivan Dogovich Youtube
Re: OpenXcom 1.1
« Reply #31 on: February 12, 2015, 11:54:41 pm »
I concur, Warboy.  The moving target is hard to cope with.  I'd gladly go with a newer milestone before TftD.  As much as I love TftD, I think that its going to be so much harder than the original, I'm probably OK, with staying here in OpenXcom enjoying mods for a while.

So count my small vote in on settling on a patched 1.1 milestone, before TftD.

Offline volutar

  • Colonel
  • ****
  • Posts: 351
  • Vanilla digger & Quality assistant
    • ICQ Messenger - 695047
    • View Profile
Re: OpenXcom 1.1
« Reply #32 on: February 13, 2015, 05:31:16 am »
I wouldn't hope for good result with the twin release concept (a. current nightly with all changes, b. stable with only critical fixes).

First of all, that would harden devs lifes (make commits and fixes for both will raise human factor mistakes). And only that alone would make that "no-no".
Second of all, devs gonna be blind in terms of bugtest with the "a" release, because community will prefer "b", and devs don't have "bugtesting crew".
Thirt, it wouldn't really help anyone, having that "half-updated" milestone.
Bottom line - I see no weighty point of going that way.

I remember when 1.0 was released SupSuper said that we should probably start making more frequent milestones. I really liked  this one, and hoped it would be for real.

And by the way, I don't see why TFTD supporting version should be named "2.0", it could be named "1.4" or "1.5" just as just another milestone.

Offline Arthanor

  • Commander
  • *****
  • Posts: 2490
  • XCom Armoury Quartermaster
    • View Profile
Re: OpenXcom 1.1
« Reply #33 on: February 13, 2015, 05:44:37 am »
Probably because 1.1 (which it would be given the current direction) is nowhere near glamorous enough for OpenTftD. And TftD is the 2nd xcom so it seems fitting..

I agree that keeping the nightly and milestone on the same branch is probably best. I will soon setup the same as Hobbs has started using, to give it a bit more momentum.

Offline Warboy1982

  • Administrator
  • Commander
  • *****
  • Posts: 2338
  • Developer
    • View Profile
    • Email
Re: OpenXcom 1.1
« Reply #34 on: February 13, 2015, 09:37:41 am »
yeah, fair enough, splitting the tree doesn't really alleviate any of the problems and probably makes things more confusing all around

Offline winterheart

  • Colonel
  • ****
  • Posts: 180
  • Fellow Squaddie
    • View Profile
Re: OpenXcom 1.1
« Reply #35 on: February 13, 2015, 12:35:56 pm »
Eh, why not create "stable" branch on git and use standard approach to release schedule?  Only we need is maintainer for that branch, who would say "Yes, this commit good enough for release candidate/release/gold" and will backport all needed fixes from master branch.

No only LPlayers and modders need stable release, package distributors from Linux also wants hard tarball with version on it.

Offline volutar

  • Colonel
  • ****
  • Posts: 351
  • Vanilla digger & Quality assistant
    • ICQ Messenger - 695047
    • View Profile
Re: OpenXcom 1.1
« Reply #36 on: February 13, 2015, 01:17:01 pm »
Eh, why not create "stable" branch on git and use standard approach to release schedule?
Why? What for? Is it necessary to multiply entities? What's wrong with keeping it as before just not to neglect making milestones?

Offline winterheart

  • Colonel
  • ****
  • Posts: 180
  • Fellow Squaddie
    • View Profile
Re: OpenXcom 1.1
« Reply #37 on: February 13, 2015, 02:35:55 pm »
Because you can't maintain stable release and backport fixes without importing all changes between stable milestone and actual fix. These changes can also have bugs.

Your approach require model "as fast as can" with 3-4 week between releases. Otherwise you cannot catch up HEAD with features and bugfixes.

SupSuper's approach (as I can see) is "ship it with huge features" with 0,5-1 year release cycle.

So my suggestion is compromise between them - "release not often but with bugfixes and small features" with 2-3 month cycle.

Offline volutar

  • Colonel
  • ****
  • Posts: 351
  • Vanilla digger & Quality assistant
    • ICQ Messenger - 695047
    • View Profile
Re: OpenXcom 1.1
« Reply #38 on: February 13, 2015, 02:48:56 pm »
Because you can't maintain stable release and backport fixes without importing all changes between stable milestone and actual fix.
Can't devs just release milestone 1.1 (from the main branch) as planned and move on as usual? Without making mess, huh? o_O

Offline winterheart

  • Colonel
  • ****
  • Posts: 180
  • Fellow Squaddie
    • View Profile
Re: OpenXcom 1.1
« Reply #39 on: February 13, 2015, 03:03:29 pm »
Can devs decide witch exactly commit is bug-free and stable as rock for 1.1? Eh?

Offline volutar

  • Colonel
  • ****
  • Posts: 351
  • Vanilla digger & Quality assistant
    • ICQ Messenger - 695047
    • View Profile
Re: OpenXcom 1.1
« Reply #40 on: February 13, 2015, 03:30:45 pm »
Can devs decide witch exactly commit is bug-free and stable as rock for 1.1? Eh?
Was 1.0 bug-free and stable as rock? Hell, no!
It's not easy to find a commit which would be more buggy than 1.0.
So the answer is - yes, certainly, to a greater extent, than it was with 1.0.

New milestone should be "stable" in the sense, which Meridian and Ivandogovich were telling. "not moving target". Not updatable until next milestone. So it's absolutely nonsense idea to make some weird fork with partial, cherry-picked commits, and to hope these commits gonna be more "bug-free" than same commits for the main branch.

Offline kikimoristan

  • Commander
  • *****
  • Posts: 649
    • View Profile
    • Email
Re: OpenXcom 1.1
« Reply #41 on: February 13, 2015, 05:48:11 pm »
Why not pick the most stable nightly and simply call that 1.1? This will advance most people who don't like the nightlies 1 year forward. Get that nightly git pull branch the one that people swear by it being the most stable one. Nothing is bug free. What you want is no game breaking bugs.
« Last Edit: February 13, 2015, 05:49:45 pm by tollworkout »

Offline Mr. Quiet

  • Commander
  • *****
  • Posts: 528
  • Likes: Quiet things. Dislikes: Loud things.
    • View Profile
    • =Open_X_Com= Mods
Re: OpenXcom 1.1
« Reply #42 on: February 15, 2015, 02:28:33 am »
So TFTD is going on hold? Well doggone it!

Before the milestone build, add something someone suggested awhile back. Letting us rename our operatives in the inventory equip screen. Just click the name and edit. Thanks to whoever came up with that. That's a feature that fans will like to see.

Offline Warboy1982

  • Administrator
  • Commander
  • *****
  • Posts: 2338
  • Developer
    • View Profile
    • Email
Re: OpenXcom 1.1
« Reply #43 on: February 15, 2015, 03:28:47 am »
no, tftd isn't on hold at all, work is progressing at full steam, we're simply discussing the release schedule

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2163
    • View Profile
    • Email
Re: OpenXcom 1.1
« Reply #44 on: February 15, 2015, 09:11:26 pm »
That is why I got really upset about. There was a definite way to 1.* version (1.1 or 1.2 or 1.5), and suddenly that changed. "WTF!" was the first thought seeing that.

There was a plan of getting that intermediate versions, at least one, with dozens of gameplay fixes and changes being made (not only crashes), and know what? - they gonna never be released until TFTD! "F that", I would say! It's not they way how things should be done! That really pissed me off, and STILL doesn't let go.

There should be really "stable" release with all noticed issues being fixed. You know, there was no stable releases. At all. 1.0 was full of hilarious bugs.
For the God sakes, let LPers and modders rely on some milestone stable release for the next 1/2 years until 2.0 come...

Sorry.
You got a lot of nerve.

First, may I remind you, that you were the one that pushed into renaming the stables as milestones, because you always found them "old and buggy". You were the one that pushed into making the nightlies more prominent on the site, if not just make nightlies the only way to download the game. You are always pushing for major changes and features for the sake of "vanillaness" which often lead to a lot of problems and bugs to be fixed later down the line. You were involved in all the recent major structural changes to the game just for TFTD vanillaness, like map scripting et all, which create a whole lot more issues. In fact if it was up to you 1.0 would never have been released because it wasn't "good enough". But sure, act surprised, insult the devs, slander our work, claim only you know what's best and just want "stability".

Second, "1.0 was full of hilarious bugs". That's funny, we've had over 100k downloads of 1.0, and I've never seen anyone suffering from such major game-breaking bugs that completely ruined their experience and made it impossible for them to play and enjoy the game. But I'm sure you're right, people everywhere just can't stop denouncing our bug-ridden mess. We would've saved a lot of time if we just hadn't bothered. After all, 0.9 was feature-complete, we could've just left it at that. Instead we spent over an year just on fixes, quality of life changes, reworking the options, mod support, saves, even including a lot of stuff you called for like integrating the Adlib music player which took a lot to get everything right, all so the community would get the best experience the deserved, a worthy milestone they could look to without needing to keep up with changes. But I guess instead we should just leave them with the nightlies, even though there's only 10 nightly downloads to every 100 milestone downloads.

After 1.0 we thought of just settling down and putting out quick releases with just little fixes and changes, but the demand for TFTD was overwhelming, and soon development just darted in that direction, so we made that our goal. This is not news, all the major changes since 1.0 have been done in the name of TFTD and moddability. The engine and battlescape changes, externalized UI, externalized globe, dual fixed weapons, map scripting, etc etc. The actual vanilla gameplay experience is largely the same. This doesn't mean we just mindlessly put out feature after feature, it means we're working towards a goal. A lot of these features have major impacts to the game, requirements brought on by TFTD keep changing them up and we may need to rethink our solutions over and over until everything's straightened out and we reach "stability". I think just stopping and leaving all these associated features half-implemented is much more dangerous and prone to bugs, as we have to support and live with everything we made for the release, and will just upset people further if we keep pulling the rug between releases.

But I also don't like reliance on nightlies. If you look at most games you will not see nightlies, at most you can only get the latest nightly hidden away somewhere. That's it. The goal of nightlies is testing and experimenting for people that can't compile code. If there is a bug in the stable, they can check if it's still in the nightly, and if so, report it. You can also use them to get testing before a release or experiment with new features. But they are a programmer tool, ever-changing with the code and should not be relied upon.
However, OpenXcom has a slow development cycle, so I conceded and let people have nightlies to get to play with stuff earlier. Now the community pretty much lives by the nightlies, and every request is answered with "get the nightly". The problem is nightlies are not releases. They are automated builds made from the latest code. These code changes can have huge to no visible changes to players. The commit logs might make sense or they might be complete gibberish. There are no instructions or installers. New nightlies might come every hour or every month. So this often just leads to tons of confusion and bewilderment as players are repeatedly told to grasp something not designed for them.
On top of that, it limits the dev team too. We can no longer do big sweeping changes and experiment as necessary, we can't do lots of small iterative changes, because every public change we make to the code is expected to be stable and working. We often have to keep adding in workarounds and compatibility for WIP changes that people ended up relying on. If we have to make anything big, we have to keep it in private for days or weeks until we're sure it's all good to go, during which none of that code can be collaborated upon.

And that, I consider a personal failure, and I am deeply sorry the OpenXcom release cycle has come to this. OpenXcom has always had a big focus on the community, and I always do my best to provide you support, but the nightlies are a big thorn in that. Not everyone may agree with me. Reading this thread, it's pretty clear not a lot of people agree with me and I don't see eye to eye with a lot of issues going on, and my posting just seems to incite more arguing and misinformation. So I'm out, I'd rather stay behind the scenes doing what work needs to be done. Warboy will handle the release schedule however he sees fit.