Collectible Card Game Headquarters

I think that we should try to keep a copy of the forge-1.0.15 archives available for the few people that may find themselves in a position where they need a java 5 version.

I have a copy of the forge-1.0.15 archives stored at MediaFire and I have a local copy just in case the forge-1.0.15 archives on GoogleCode are deleted.

Releases after forge-1.0.15 can require java 6. Would it be a good idea to increase the version number up a notch? I guess that the next beta would be forge-1.1.01 ?

Chris H. wrote:Releases after forge-1.0.15 can require java 6. Would it be a good idea to increase the version number up a notch? I guess that the next beta would be forge-1.1.01 ?

that sounds reasonable. i hope to have something i can commit tonight to formalize the need for java 6.

Chris H. wrote:I think that we should try to keep a copy of the forge-1.0.15 archives available for the few people that may find themselves in a position where they need a java 5 version.

I have a copy of the forge-1.0.15 archives stored at MediaFire and I have a local copy just in case the forge-1.0.15 archives on GoogleCode are deleted.

Releases after forge-1.0.15 can require java 6. Would it be a good idea to increase the version number up a notch? I guess that the next beta would be forge-1.1.01 ?

Yes. Sounds good. you will have to update the version number in the pom.xml. Also, there is a version number down in the Windows profile that builds the .exe file. you will need to update that as well. Unfortunately, I have not automated that yet since the Windows .exe does not like "-SNAPSHOT" appearing in the version number.

jendave wrote:Yes. Sounds good. you will have to update the version number in the pom.xml. Also, there is a version number down in the Windows profile that builds the .exe file. you will need to update that as well. Unfortunately, I have not automated that yet since the Windows .exe does not like "-SNAPSHOT" appearing in the version number.

`
I see that you were able to automate the Launch4j version numbering. Thank you, that should simplify things.

I went ahead and changed the pom to version '1.1.00". It should now be ready for the next release in a couple of weeks.

Chris H. wrote:Releases after forge-1.0.15 can require java 6. Would it be a good idea to increase the version number up a notch? I guess that the next beta would be forge-1.1.01 ?

Is it worth creating a Java5 branch for critical fixes? Like a 1.0.15 release branch. We've got plenty of room in the repo. Keep it around for a while, then if all's quiet for a few months, we can do away with it.

-slapshot5

slapshot5 wrote:Is it worth creating a Java5 branch for critical fixes? Like a 1.0.15 release branch. We've got plenty of room in the repo. Keep it around for a while, then if all's quiet for a few months, we can do away with it.

-slapshot5

`
It might be worth it. I would hate to see our team spend it's limited time in too many different code branches. Braids said that she was having a difficult time merging the changes from the main trunk into hers.

slapshot5 wrote:Is it worth creating a Java5 branch for critical fixes? Like a 1.0.15 release branch. We've got plenty of room in the repo. Keep it around for a while, then if all's quiet for a few months, we can do away with it.

from what i understand of subversion it is very efficient with space. even if you make an entire branch, which appears to copy the entire tree, it takes up little space. especially if you use svn copy with two urls, bypassing your working version.

speaking of branches, i'm going to see if using a different diff3 engine makes merging any easier.

Chris H. wrote:It might be worth it. I would hate to see our team spend it's limited time in too many different code branches. Braids said that she was having a difficult time merging the changes from the main trunk into hers.

There wouldn't be any merging. Nothing would go into this branch unless something is unplayable in that branch and someone wanted to fix it. It would not be getting new development.

-slapshot5

Braids wrote:from what i understand of subversion it is very efficient with space. even if you make an entire branch, which appears to copy the entire tree, it takes up little space. especially if you use svn copy with two urls, bypassing your working version.

speaking of branches, i'm going to see if using a different diff3 engine makes merging any easier.

Branching uses svn copy which doesn't move files unless they change. As soon as they change you get 2x the storage.
What you said is true for the next generation source control software like mercurial or git, where branches are handled by difference only.

You might want to read this. However it isn't the only knowledge you would need to work with git svn bridge.

slapshot5 wrote:There wouldn't be any merging. Nothing would go into this branch unless something is unplayable in that branch and someone wanted to fix it. It would not be getting new development.

but if something was fixed in the branch, i'm guessing we would want to incorporate it into the trunk. the safest way to do that is with a merge.