Forge version 1.3.1

[Chris H.]

Starting a next version thread.

Tentative release target date: Friday November 2nd (or earlier) if our current release is buggy.

[RumbleBBU]

It is...

Ah, and my commit of the RtR Guild Sealed Deck block narrowly missed this beta. Oh well. Maybe that's for the better, I haven't extensively tested the block yet.

[Max mtg]

So, when do we increase minor version number for the next time?
Or... what needs to be done? OpenGL Match UI? Network play? Our own DCI with blackjack and hookers?

[RumbleBBU]

Chris, I know you're probably in the middle of uploading and/or announcing 1.3.1 right now, but please take a look at r17822 ( http://svn.slightlymagic.net/websvn/lis ... &rev=17822 ), committed just after your snapshot.

It fixes a bug that I think is pretty major for the new unlocking code.

Before that fix, you could unlock all you wanted, but the unlocking info and the cards you got would never be saved! Fortunately, your paid money wouldn't be saved either, but it's still a pretty major one IMO.

(I have absolutely no idea why this did work for me yesterday without that save() call.)

[Chris H.]

Chris, I know you're probably in the middle of uploading and/or announcing 1.3.1 right now, but please take a look at r17822 ( http://svn.slightlymagic.net/websvn/lis ... &rev=17822 ), committed just after your snapshot.

It fixes a bug that I think is pretty major for the new unlocking code.

Before that fix, you could unlock all you wanted, but the unlocking info and the cards you got would never be saved! Fortunately, your paid money wouldn't be saved either, but it's still a pretty major one IMO.

(I have absolutely no idea why this did work for me yesterday without that save() call.)

 
I think that we should wait a week or two until the 1.3.1 beta release. I do not think that anyone found a major bug in the previous release that would require a quick fix release.

I would also like to give us enough time if possible for Sloth to get back from his vacation and to let Sol get his electricity back.

[Chris H.]

Chris, I know you're probably in the middle of uploading and/or announcing 1.3.1 right now, but please take a look at r17822 ( http://svn.slightlymagic.net/websvn/lis ... &rev=17822 ), committed just after your snapshot.

It fixes a bug that I think is pretty major for the new unlocking code.

 
Today's snapshot build includes RumbleBBU's fixes although it looks like Marc's fixes will be included in tomorrow's snapshot build.

[moomarc]

Chris, I know you're probably in the middle of uploading and/or announcing 1.3.1 right now, but please take a look at r17822 ( http://svn.slightlymagic.net/websvn/lis ... &rev=17822 ), committed just after your snapshot.

It fixes a bug that I think is pretty major for the new unlocking code.

 
Today's snapshot build includes RumbleBBU's fixes although it looks like Marc's fixes will be included in tomorrow's snapshot build.

Mine wasn't a fix so much as finally getting the token image info in for RtR at last. Sorry it's taken so long.

[Chris H.]

Starting a next version thread.

Tentative release target date: Friday November 2nd (or earlier) if our current release is buggy.

 
I think that we should consider waiting until the end of the month to give us all a chance to fix and finish a few things.

[Chris H.]

Mine wasn't a fix so much as finally getting the token image info in for RtR at last. Sorry it's taken so long.

 
Thank you. I added this and the new RtR set pics as a fluff piece. I like to give the users something to read that is not too techie orientated.

[Max mtg]

I have added a developer option "add card to play". This does not just a card to a player's hand but makes him play that card (for no mana cost). This way it will be easier to reproduce situations like "AI has (certain cards in play) and (something does not work)"

[Max mtg]

Some stats to compare about recently refactored abilityfactory package

r17736: 38 files, 1 679 770 bytes
r17907: 189 files, 1 020 011 bytes.

As a result of this refactoring some 650 kilobytes of duplicate code were eliminated.

[Sloth]

I think the code base is not in a bad shape at the moment. What about a release at the end of the week? Or are there any show stoppers?

[Chris H.]

I think the code base is not in a bad shape at the moment. What about a release at the end of the week? Or are there any show stoppers?

 
Sounds good to me and I am not aware of any show stoppers myself. If no one objects then I will release the beta on Friday November 16.

[RumbleBBU]

I haven't had as much time for Forge in the past few weeks as before...but whenever I get the newest SVN checkout, there always seems to be something broken that used to work. Sometimes I can figure out what and why, sometimes I can't. And even if it works today, it probably wouldn't work tomorrow when somebody commits some new features...

Personally, I would like to see a 'code-freeze' period of, say, a week or two before the next beta. During that period, only bug-fix commits would be welcome. New or partially implemented features (like my quest worlds code) could wait until after that.

(Case in point, I'm keeping a separate 'working' codebase for actually playing Forge - it's basically 1.2.15 with my own quest code changes thrown in. I would have loved to update that codebase, but every SVN checkout after that has broken something I would very much love to use, like challenges with preset cards, or the custom quest formats, which are broken in the current SVN.)

[Agetian]

I believe each approach has its upsides and downsides, though when organized correctly, I believe the code freeze may actually be beneficial - that's really the issue with the rolling release format, some things get fixed and others get broken and there's little one can do about it unless there is some stabilization period set up. I believe that if the others don't mind, a scheme like that can be employed, but there are two potential issues that need to be sorted out before we go for it:
1. The system of code freeze must be transparent for all developers - it must be clear when the code freeze starts and when it ends. Also, I don't think it should be very long for a project like Forge which is on a practically monthly beta release schedule - perhaps, 3 weeks for active development and 1 week for fixing up?.. (might need some experimentation, actually, to see how it works out).
2. The potential issue might be the synchronization of different coding efforts when the code freeze ends and the major modifications time comes again - with all developers potentially secretly working on some major projects, each of which can potentially affect the interface and locations of various portions of the code, it might be hell of an effort to synchronize everything when several developers submit potentially conflicting major changes to the code base after the code freeze is over - committing smaller changes sometimes makes a lot of sense, a good example is my recent AF ChooseSource commit, I was only working on it for a few days and when the commit time has come, I figured out that the public interface of the ability factories has changed and my code, when committed in its original form, broke the compilation and needed updating. :\ Not sure what can be done with it, to be honest - unless, of course, we all decide that we do major developments for 3 weeks, then we all stop and fix bugs during the code freeze, and then we resume our major developments.

At any rate, I think that further discussion may be welcome, and I'm ready to go with whatever decision we all come up with in the end.

- Agetian