Version Numbers

[Punboy]

An interesting problem arose recently with the release of 1.3.3. After all was said and done about the bugs in the system, Leviathan packaged up a "new" version of 1.3.2 and started releasing it, calling it... 1.3.2. However, there already was a 1.3.2 in circulation.

As far as I know the 1.3.2 Levi was producing is not compatible with the 1.3.2 everyone already had, because there were changes to the sheets and such. Thus, 1.3.2 is not longer truly 1.3.2

This can be very confusing for the end user. its my believe that there should be different a different versioning system, and this is how I think it should be.

There should be an EXE version. At this point, the latest stable is 1.3.2
There should be a separate version for the sheets.
And last but not least, there should be a release version.

In the case of the recent release by levi, it should have been Release 1.3.2.1. With EXE 1.3.2, blah blah blah. This would keep people from being confused.

Any thoughts?

[zigzagjoe]

the one i'm distributing is v1.3.2 w/ natfix and borehole

orig map names etc

[Punboy]

You shouldn't be distributing a version at all, joe.  

[zigzagjoe]

until the maps are fixed, i will not even consider it

[Punboy]

Joe... cease and decist. lol.

[zigzagjoe]

lol no

[BlackBox]

You need to stop distributing a version zigzagjoe.
You just are creating more confusion for players.
We as OPU have already refused to recognize your version as anything "official." (which it is not).
If you continue to distribute a modified version like you are, you might end up being banned from IRC, or possibly from the site too.
So I'll ask you one last time. Cease and decist, or face the consequences.

---------------------------

I think ultimately what we may have to do, is go to the next version number once all the bugs are worked out. (1.3.4)

And making a 1.3.2.1 wouldn't be possible, as the OP2 versioning system only supports a 3 digit version code. Changing that would require extensive changes to the networking layer and other version control code.

[Hooman]

Yes, adding more versions just adds to the confusion.

Changing the version number once all the bugs are fixed sounds like a good idea.



Also, as we've suggested before, they way these releases are brought out really needs to be changed. I know I've contributed to the problem by making last minute changes to Hooville, but this kind of thing needs to stop. We should set an update deadline for when all updates that are going to be released have to be finished and submitted. This should be well before release time. Probably a week or so. Then if bugs are found, we'll have time to fix the package before a major release. It wouldn't hurt to designate a few trusted gamers to test out the package. People who will keep quiet about any suprises you might like to have included? (Reasonable surprises, like cool new levels).

We NEED a changelog. In fact, we should post the changelog at about the time all updates need to be in. (Maybe a day or two later to allow for documenting last minute changes made before the update deadline). This changelog should be detailed and posted on the forums so people will read it and can have time to discuss it, or launch objections. It wouldn't hurt to post intended changes for the next update well before this submission deadline. Also, a changelog of exactly what ends up getting released should be made available in time for the release (probably with it). This will acount for any differences with the intended version and what gets released, due to perhaps removal of certain items due to bugs.

We should be fairly strict about the deadline. If something isn't ready, it'll have to wait for the next release. We also need some rules about bug fixes. If something was submitted but is buggy, we either need to revert back, or fix the bug. If an attempt is made to fix it, then time must still be available to test the fix. Maybe save the last 3 days before a release for text file changes only (change logs, credits, instructions?, etc.). Any bug fixes will have to be incorporated before this point. If any major bugs are found after this point, the item in question will simply be removed, no fixes allowed. Any fixes will have to wait for a future release for the item to be incorporated.

Of course, no set of rules is perfect. If we need to deviate from whatever rules are set out, a post should be made about it. It shouldn't be carried out by one or two individuals who are responsible for packing up all the changes. We don't really want changes done in secret. Perhaps if a major important update becomes available a day or two after the submissions deadline? It'd have to be an important change, whatever it is, and should obtain a rough concensus. Perhaps a post describing the potential addition to the package, and a few replies approving of the idea? Providing there are no major objections, I guess it could be done.


Well anyways, I'd also like to say that if an update can't be completed by the scheduled release time, it should either be cancelled or rescheduled. It's a pain in the ass to fix things once they're out, or to find and sort through unexpected bugs. (Not just for the programmers, but the players too). When this sort of thing happens, it'll probably lead to decreased interest overall in anything to do with the updates or Outpost2.


Lastly, maybe we need to rethink this strong coupling between released and reunions. They don't *have* to coincide. I can see why they do. It's certainly ideal to have the two go together, but we shouldn't get stuck with the mentality that they're the same thing. If we feel we have to cancel an update/release right before a reunion time, then maybe we should go ahead with the reunion without having an update. People may try to schedule themselves to be free on reunion weekends, so you might not want to cancel that with the update. Also, there are certain things that should be released as they become available and we shouldn't sit and wait for a reunion to release them. Things like the NATfix or map editors should probably be released as they become available. It's probably better if things like that are released before reunions so people can play and practice up, or work on new maps or whatever for the next reunion, or update, or whatever. Of course, it's still a good idea to include things like the NATfix with an update package, but there is nothing wrong with providing that as a seperate download.

 

[zigzagjoe]

Hacker: You can ban me to hell for all I care.


Until what i see is necessary is done (maps reverted), I will never Stop.

I will always be here. Wither You and Levi like it or not.

I will return in a day or too.


Good Bye.

[Leviathan]

I agree Hooman, its never been done right, the update should be 100% done and tested before it gets released. We can do that from now on.

I agree with the map naming, each map should have a number like the files are originaly named. And if there is two LR's etc of that map then u could use a a after the number or whatevea.

Joe im glad your allways be with us.

Because a few people dont like the few map names we changed we have no reason to change it back.

[BlackBox]

I agree with Hooman.

We have been *WAY* too lazy as to when updates are made, released, etc.
Also, I agree, what is part of the update needs to be a more general concensus of everyone, not just a couple of us. (Eg. the whole OPU Team should be working together on the updates).

Patches, changes, whatever NEED to be tested better before we actually release them. (Even if it is a fluke thing, like what happened with the sheets files causing the crash)
That way it would prevent all the fixes/updates to the updates we have to do. (What you mean about the people losing interest in updating or the game in general, I understand. As well as it's stressful on the people who are making the updates)

I think the best time to start deciding when to release an update is the week immediately after a reunion / last update. (And the update doesn't have to get a time set, I think we could release updates anytime. Actually I prefer not having to meet a deadline for an update when it goes with something major, like the reunion. That puts a lot of stress on people who are frantically trying to finish maps, or whatever else goes into it, and there are more bugs because the developer was in a rush to finish whatever it was).

-------------------

zigzagjoe: From making the fuss you've made over something as simple as the map name changes, you've shown me that you have the maturity of a small child.
No one likes every single change that happens (including me and Levi. I wasn't the most thrilled with the map name changes, but I can deal with them) but that doesn't give you a reason to whine about it again and again. Simply adjust to the change like a mature responsible adult can, and there's no problem.

I'll give a parallel: You may not like what leader is elected for your country, but most people don't continually go around and whine about it for months on end. (People who do, tend to be looked down upon).

However, we cannot have you trying to create problems for other people by trying to get them to download 1.3.2 when we now have a perfectly working 1.3.3 version for people to play. By doing this, it creates problems for everyone. Just because you don't like a small insignificant change in something doesn't mean everyone else hates it too.

You are in the minority, of the people who can't put up with something this small of a change.

Though I hope you stay with us, I hope you can cooperate with changes that occur. It's the best thing for the whole community.
 

[zigzagjoe]

Talk to the poll.

2-for
4-against

That means i am not alone.