MapTool 1.3 Development Build 54 progress

[cubeblue]

If we keep requesting features, we'll never get to a stable release.

[Amaril]

If we keep requesting features, we'll never get to a stable release.

QFT.

Everytime we get a new feature, there's a chance it has a bug. Then we have to waste another dev build to fix those bugs. This is turning into a vicious cycle, and I think we need to get off the merry-go-round.

[Jector]

Another Georgian for stabilizing then adding new bugs.

[Mrugnak]

Some of these features have been promised for months. And some of them worked in 1.2, but were killed off early in 1.3 with vague promises of them being re-added before 1.3 goes stable.

But mostly I want the horrible problems with hexagonal tokens larger than one cell resolved before we go stable, and those are bugs

[Amaril]

Some of these features have been promised for months. And some of them worked in 1.2, but were killed off early in 1.3 with vague promises of them being re-added before 1.3 goes stable.

But mostly I want the horrible problems with hexagonal tokens larger than one cell resolved before we go stable, and those are bugs

Some, but not all. I support the features in those cases, but there are some new features added by contributers that are beyond restoring former features, and it is those truly new features that are hindering finalization of a stable build.

[Amaril]

Another Georgian for stabilizing then adding new bugs.

That's actually kind of funny.

[jfrazierjr]

Some of these features have been promised for months. And some of them worked in 1.2, but were killed off early in 1.3 with vague promises of them being re-added before 1.3 goes stable.

But mostly I want the horrible problems with hexagonal tokens larger than one cell resolved before we go stable, and those are bugs

Some, but not all. I support the features in those cases, but there are some new features added by contributers that are beyond restoring former features, and it is those truly new features that are hindering finalization of a stable build.

No, the features contributed over the last 15 builds by various members are so are in no way hindering finalization of 1.3. Trevor's internal road map is the only thing that is hindering 1.3, so until Trevor has completed adding all the new features he has decided must be part of 1.3, everything else is on top and there is zero reason to not add such new features unless Trevor has some specific lines of though on how he wants them done to make the other developers backtrack on their work.

[Amaril]

No, the features contributed over the last 15 builds by various members are so are in no way hindering finalization of 1.3. Trevor's internal road map is the only thing that is hindering 1.3, so until Trevor has completed adding all the new features he has decided must be part of 1.3, everything else is on top and there is zero reason to not add such new features unless Trevor has some specific lines of though on how he wants them done to make the other developers backtrack on their work.

Really? So as long as trevor's work is done, he'd release it as a stable release regardless of whether or not those contributor's bugs are resolved? And there's never been a release that mostly been comprised of such bug fixes and/or new features?

[applekor]

No, the features contributed over the last 15 builds by various members are so are in no way hindering finalization of 1.3. Trevor's internal road map is the only thing that is hindering 1.3, so until Trevor has completed adding all the new features he has decided must be part of 1.3, everything else is on top and there is zero reason to not add such new features unless Trevor has some specific lines of though on how he wants them done to make the other developers backtrack on their work.

Really? So as long as trevor's work is done, he'd release it as a stable release regardless of whether or not those contributor's bugs are resolved? And there's never been a release that mostly been comprised of such bug fixes and/or new features?

As one of the offending contributors , I have to agree with Amaril. Our new features have caused a fair number of bugs along the way. As such, I'm trying to finalize a few more last minute macro tweaks for b54, then I'm personally done adding new stuff to 1.3.

[jfrazierjr]

No, the features contributed over the last 15 builds by various members are so are in no way hindering finalization of 1.3. Trevor's internal road map is the only thing that is hindering 1.3, so until Trevor has completed adding all the new features he has decided must be part of 1.3, everything else is on top and there is zero reason to not add such new features unless Trevor has some specific lines of though on how he wants them done to make the other developers backtrack on their work.

Really? So as long as trevor's work is done, he'd release it as a stable release regardless of whether or not those contributor's bugs are resolved? And there's never been a release that mostly been comprised of such bug fixes and/or new features?

But thats just the thing, Trevor has not completed all of his promised features(and frankly may not), so it does not matter if new features are introducing a few bugs at a time or not.

Also, Trevor is still stamping out long term bugs or optimizations in code that no contributor has touched at all. Once the feature freeze, which should be next release, I still expect 3-5 releases for Trevor to work out bugs in stuff he has been working on at a minimum. This also gives Craig time to get bug fixes done for stuff he has added over the past 6 months. In any event, if no one else added stuff over the past 6 months other than Trevor, I still don't see that we would have a final release today unless Trevor decided to forgo stuff he wanted to put in, and I just kind of doubt that would be the case.

I don't know about you, but for me the macro changes, even if I have to eventually rewrite them in javascript (which I have no problem doing when the time comes) have made my games 100 better and 5 times faster. The automation (partial) aspect is one thing for me that would be my number one feature request. Aura's a great, square light is great, projector mode(won't be done in 1.3 though it was promised) is great, etc,etc, etc, but being able to automate my game is critical to speeding up my game while the other stuff is just "nice to have."

In any event, Trevor has plainly said that b54 is it for new features (though, personally, I would not put it past him to sneak 1-2 things in even if he does not let others do so.) Personally, I have played with pretty much every release since 1.3b30 or so in some form or another and would have no problem if I had to stick with b53 for several months since it's pretty solid.

[jfrazierjr]

Any chance of square vision being added in 1.3 or will that be a 1.4 feature?

[Azhrei]

In any event, Trevor has plainly said that b54 is it for new features (though, personally, I would not put it past him to sneak 1-2 things in even if he does not let others do so.)

+1 for truth.

I've backed out the networking fix I put in for people with whacked out networking code because that was feature with a bug. I'm pretty good at those.

But if features are added in parallel to Trevor's GUI stuff, I don't see that as a problem. The problem is when they have bugs that _don't_ get fixed. Which is another reason why contributors having branch access to SVN would be a good thing. I could commit a feature to a branch that I considered finished. If I started making changes elsewhere, I could revert back to that branch and not all the way back to the latest public build! At one point, I was working on a third set of features/fixes and that would've meant a lot of lost work to go back to the public build. Additionally, this code only exists on my laptop -- if it goes *poof*, so do those features/fixes...