MapTool via SVN, Revision 5591

[Azhrei]

I just committed revision 5591 and I need some serious testing done!

Please check the ChangeLog -- there's a buttload of stuff changed and I need to get as many eyeballs on this as possible to make sure those things have been fixed.

We know that there are still a few items remaining: some fog-of-war issues, the resize/rotate of objects is still a little funky, some images don't display after campaign load until a zoom in/out occurs, and movement of tokens sometimes doesn't show a distance label. We will be tackling those over the next few days. The dev team wants to do an internal "playtest" session before the last build and we'll need to schedule time for that, so Final could come as early as the middle of next week (January 26th or so). If I can get one bug fixed per day, and out playtest happens quickly, we should be able to make that...

If you find anything else, I want to hear about it! No matter how minor! (Although if it's tough to fix, it might have to wait. But minor problems that have minor, ie. "easy" fixes will get taken care of before Final.)

[aliasmask]

Why not just release it as a Release Candidate and if it passes snuff, rename it to Final. RC1 and 2 didn't really make it too far out the gate before discovering serious bugs. That way the whole community can test it.

[Azhrei]

I suppose that's possible. I really wanted the next one to be Final though!

We'll see what Dorpond says, as I trust his opinion on such things.

[DarkWiz58]

I suppose that's possible. I really wanted the next one to be Final though!

We'll see what Dorpond says, as I trust his opinion on such things.

Look, after developing code and managing small and very very big programming projects over more than two decades, I feel the need to pass on some advice I often have to give my crews:

The release number is just an abstract tag, one out of an infinite set.

Don't get hung up on what the number is !

Everyone prefers a tested, solid release to one that requires an immediate update.

Bad code is worse than missing a schedule. It lasts forever. See microsoft versus apple, for example.

Just sayn'

DarkWiz58

[Azhrei]

Everyone prefers a tested, solid release to one that requires an immediate update.

Heh-heh, yep. I agree.

I just wanted to put this thing to rest and move on to 1.4! So... one more build and then be done with it.

But I think we're going to need two builds anyway. Even after we get the current fix list resolved we're going to want some community testing...

[DJuego]

The release number is just an abstract tag, one out of an infinite set.

Don't get hung up on what the number is !

Everyone prefers a tested, solid release to one that requires an immediate update.

Bad code is worse than missing a schedule.

I agree COMPLETELY with these comments.

My very humble opinion:

In order to be considered reliable, the previous versions to official releases should not suffer so many changes. But now, The test stage must be restarted.

In this last iteration, the change log density is frightening. Magnificent( ) but frightening. I am sure that some new and unfortunate error has inadvertently been introduced. Any critical bug probably.

The fantastic Dev Team already has enough fixing up bugs. And they are tired and bored of Maptool 1.3.
The 'SVN Team' is too small and they don´t play real games with the SVN version.
The test must be open.

A very cruel comment: The community should talk now or shut the mouth forever about the Maptool Release version quality. ( ).

Two observations:

a)I recommend to create a public and notorious list of known errors but that will not be fixed due to complexity. And if it is avalaible to show the workaround.

b)I believe that cleanliness of the Bug Reports subforum should be done. There are a lot of active reports that already have been solved. In a ideal world, the bug report author should confirm the fix with a last answer ( ).

I repeat: My very humble opinion.

Sorry for my English

P.S. On the other hand, in the 'worst-case scenario' I do not think that we have to get shocked for Maptool-1.3a, Maptool-1.3b, Maptool-1.3c,...

DJuego

[Azhrei]

In order to be considered reliable, the previous versions to official releases should not suffer so many changes. But now, The test stage must be restarted.

It's disappointing to me, but I think I must agree. The change list is too large to expect a single build will suffice for Final...

a)I recommend to create a public and notorious list of known errors but that will not be fixed due to complexity. And if it is avalaible to show the workaround.

This is a very good idea. We'll need a volunteer to coordinate things. Someone who reads most of the threads here on the forum so they're familiar with what's happening with the code, although it doesn't need to be someone who's actually using MT at the moment. This is mostly an administrative assignment, not a technical one.

b)I believe that cleanliness of the Bug Reports subforum should be done. There are a lot of active reports that already have been solved. In a ideal world, the bug report author should confirm the fix with a last answer ( ).

whited has worked to clean up the 1.3 bug tracker listing and we used what was left to build a list of ideas for 1.4 features. But I agree that the BugReport forum could use some insecticide.

If someone wants to take on this important task, I'll make them a forum moderator. They can skim through the forum and prune away the bugs that have been fixed or have workarounds (perhaps with links?). In both cases, moving them into the "Fixed" sub-sub-forum.

[zEal]

a)I recommend to create a public and notorious list of known errors but that will not be fixed due to complexity. And if it is avalaible to show the workaround.

This is a very good idea. We'll need a volunteer to coordinate things. Someone who reads most of the threads here on the forum so they're familiar with what's happening with the code, although it doesn't need to be someone who's actually using MT at the moment. This is mostly an administrative assignment, not a technical one.

b)I believe that cleanliness of the Bug Reports subforum should be done. There are a lot of active reports that already have been solved. In a ideal world, the bug report author should confirm the fix with a last answer ( ).

whited has worked to clean up the 1.3 bug tracker listing and we used what was left to build a list of ideas for 1.4 features. But I agree that the BugReport forum could use some insecticide.

If someone wants to take on this important task, I'll make them a forum moderator. They can skim through the forum and prune away the bugs that have been fixed or have workarounds (perhaps with links?). In both cases, moving them into the "Fixed" sub-sub-forum.

Unless someone else is dying to do this, I'll volunteer to clean up the Bug Reports forum. Instead of skimming though, I'd try to be a bit more thorough to attempt to create a list of known bugs and workarounds in the process.

[DJuego]

Thank you very much, zEal.

I did not propose my candidature because I considered that somebody with an indigenous knowledge (or very good) of English would be undoubtedly preferable.

My English is very bad.

DJuego

[Azhrei]

Thank you very much, zEal.

Agreed! Going, going... SOLD!

My English is very bad.

DJuego

Bah! Your English is better than my... anything, really.

Perhaps you'd like to work on a translation instead? We have quite a few already, but maybe there's a gap? Or perhaps you'd just like to check someone else's work? It's always better to have lots of eyeballs looking at this stuff...