I'd like to request to be a "collaborator" on the project so that I can at least help by labeling topics. I'll start with the default labels Github provides until we decide we want more. Reasonable? 😄

Maps is still in sourceforge? Atari map has a bug where "Factory.png" is used instead of "factory.png". A person only see this problem on a case sensitive file system. Seeing that reminded me maps are not in git. @veqryn , will you be moving maps into git? Second thing I wanted to ask, can we check in the map files in an expanded format (not compressed in zip)? Allows for easier modification, building would be simply zipping stuff up.

I'd like us to agree on a continuous integration process and to document it on the github wiki.

Definition: continuous integration means the work of multiple developers is integrated together on a short iteration cycle. Meaning, merge conflicts that come up are small and not so frequent.

Proposal: simply use master branch for integration. Pull requests will add new code, "git pull --rebase" to pull down remote code and integrate it locally.

You can push github release artifacts by hand.

Admins should see an "edit" button next to each release: https://github.com/triplea-game/triplea/releases. Clicking on that there is a section to 'drag and drop' files and add them to the release.

For this issue, please populate some of the releases with build artifacts.

We have a long list of pull requests sitting around. They're small and focused as requested, sometimes even trivial like #33. So perhaps size or complexity of a pull request is not the reason they are not being merged.

So what is going on? Why are so many pull requests sitting around? What are the various things we can do to address this problem?

edit skipping the details of why this is a problem. I'd like to keep this discussion as matter of fact as possible. Though without further elaboration, I'll state this is a very significant problem in my point of view.

Here are the commands to tag (assuming you are one of @veqryn or @ron-murhammer and have cloned the triple-game repo already):

$ git fetch origin
$ git tag -a v1.8.0.7 -m '1.8.0.7'
$ git push origin --tags

Anything blocking us from adding the tag? Are we set to do a release from the current version?

Anyone have any thoughts or desire to change how the various game settings are presented to users?

Some problems we have:

• settings a a bit scattered between the various menus
• settings can be ambigious, "focus on own casualties" without more context could mean a lot tof things.

Some possible ways to improve:

• tabbed settings window, 3 or 4 column layout: <name, value, recommended value, description>

Why?

• The settings are getting a bit scattered, adding more could make things kinda gnarly. Would be nice to organize settings now while we have fewer. That will help give a cleaner framework for adding more.

Please assign to @ron-murhammer

Code to do it would look something like this:

( https://reviewable.io/reviews/triplea-game/triplea/54#-JwSqFD6mzl6vTFqIOEF, ProPurchaseAI.java)

    /*
       * Currently the place delegate does not accept bids by the AI to territories that it does not own. If that gets fixed we can add the
       * following code in order to bid to allied territories that contain our units (like Libya in ww2v3) (veqryn)
       * for(Territory alliedTerr : ourFriendlyTerr)
       * {
       * if(!Matches.isTerritoryOwnedBy(player).match(alliedTerr) && alliedTerr.getUnits().getMatches(Matches.unitIsOwnedBy(player)).size()
       * > 0)
       * {
       * ourSemiRankedBidTerrs.add(alliedTerr);
       * }
       * }
       */

Question 1 - How do we keep track of priorities of what needs to be done? Do we have a wiki page with some mission statement items, maybe more granular with general things to improve? Do we supplement that, or only do prioritization in whatever project tracking mechanism we choose?

Question 2 - Does this process take into account that some contributors will only be able to work on low priority items?

Unless my arithmetic is off, we have 27 files at the top level folder and 16 folders. This is quite a lot of content at the top of the project folder. Consider we are rebuilding our build system (ant to gradle), it should be a good time to move to a more organized folder structure.

Below is a summary of how many files we have by file extension type:

~/work/triplea$ find . -maxdepth 1 -type f  | sed 's/.*\.//g' | sort | uniq -c | sort -nr
      6 xml
      6 sh
      3 bat
      2 txt
      2 plist
      2 gradle
      2 exe
      1 vimrc
      1 properties
      1 pdf
      1 md
      1 ini
      1 html
      1 /gradlew
      1 gitignore
      1 docx

The 6 XML files include:

$ ls *.xml
build.xml            launch4j_embedded_jre.config.xml
digests-include.xml  triplea_java_eclipse_cleanup.xml
launch4j.config.xml  triplea_java_eclipse_format_style.xml

3 of those files look like logger files that just need to be on the classpath. Standard thing to do AFAIK is to have a "resources" folder for this. For us, we can probably put these files in data or assets maybe since those are on most paths. We could also create a resource folder to house them.

The two eclipse xml files could use a home, likely with other IDE files.

The 6 *.sh and 3 *.bat files can likely go into a scripts folder.

There looks to be a long tail of documentation files, we can probably organize those in a docs folder.

I'm interested to hear thoughts if this is reasonable, and or alternatives or improvements/additions.

For convenience, here is the listing I get from the top level tripleA folder:

~/work/triplea$ ls
assets                            maps
bin                               old
build.gradle                      readme.html
build.xml                         README.md
changelog.txt                     run-headless-game-host-mac-os.sh
data                              run-headless-game-host.sh
dice_servers                      run-headless-game-host-windows.bat
digests-include.xml               run-server.sh
doc                               ServerInfo.plist
fix_mac_icon.sh                   settings.gradle
gradle                            src
gradlew                           system.ini
gradlew.bat                       test
icons                             triplea_embeded_jre.exe
Info.plist                        triplea.exe
installer                         triplea_java_eclipse_cleanup.xml
junit                             triplea_java_eclipse_format_style.xml
launch4j.config.xml               triplea_mac_os_x.sh
launch4j_embedded_jre.config.xml  TripleA_RuleBook.docx
lib                               TripleA_RuleBook.pdf
license                           triplea_unix.sh
MacOS_users_read_this_first.txt   triplea_windows.bat

Let's establish exactly how release patches are to work. Both of these routes are okay:

• submit 2 PR, one for the release branch and a second for master. Benefit: the change to master can be different, (perhaps more comprehensive, non-existent if the patch is only needed for that release, or very different if a lot of changes have been done and lots of merge conflicts would exist). Con: you get an extra PR, need to keep straight which PR goes into which branch.
• submit 1 PR to the release branch, release branch is merged back into master. Benefit: only one PR. Con: commit to master and release branch must always be the same. Second con, doing merges, generally keeping a linear commit history is a best practice.

I thought we would go with the first, but looks like we are doing the second. Let's discuss.

Some lightweight discussions would be nice via email.
LIke for example, hey Mr xyz repo owner, I've an interesting change on this branch in my fork, could you look at and tell me what you think?

Some things don't deserve a github issue I think. What do people think, create an email distro? Probably would be a google group.

Also nice thing, for short more informational messages, it would reduce our reliance on creating issues on the more transient, developer interested only topics.

So we have a few users that are having technical difficulties with the latest release on a Mac. Does anyone have a Mac and can help debug?

Low priority, but I want consensus on this so we can do this while we move along on to bigger items. Below are some items that are somewhat whacky things going on in class files. I propose we fix the items below in an ad-hoc manner (and if someone really wants to, they can do a sweep and get everything!):

1. License on top of most files
   -- It's not up there everywhere on every file. Let's post a copy with the source code and in this wiki.
2. @author comment in javadoc
   -- We have git that tells us who authored what and when, it's not necessary to have this. Plus, I always wonder, okay, I've now modified 10% of this file, do I update the @author, how about at 70% when the file is starting to look completely new? Why are we bothering with those questions?? Let's worry about code!
   -- Admittedly, this is a bit controversial, it's nice to have that @author at the top of the file. At the end of the day though there is very little value in having it there.
3. delete commented out code
   -- religious removal, just delete it. Any objections?
4. methods that can be marked as static, mark them as static
   -- indicating there are no instance dependencies is a good thing, let's do it.
5. empty javadac annotations
   -- if there is nothign more than the name of a parameter, I'd rather not have it. It's one less thing to worry about when updating the parameter. Plus, am I the only one that when there are more than 3 javadoc @params, I immediately check their names and counts against the actual method. Unless we add value, let's not add maintenance burden.

I heard Travis suggested as a continuous build tool. Free for open source, seems attractive. An alternative would be bamboo, but IMO I like the idea of staying in GitHub + Travis tools for now as a good thing.

edit updated to add #65 to list

If i had my preference of which PRs should be merged first and in which order:

Add Travis CI config and fix Junit tests run from Gradle

58 opened 3 days ago by DanVanAtta

• I'm building all new branches based on the branch in this PR. Means you'll see these common commits a lot in recent PRs. Adding travis is really helpful, and fixing the build is just important.

Game freezes on startup - Game chooser synchronize deadlock fix

66 opened 39 minutes ago by DanVanAtta

• Bug fix! Ever since I did the last merge of the latest reformat changes, my master (and even rolling back to before #58), started seeing this problem. I got a stack dump and found where the deadlock was. Not sure how/why, but the fix is works at least. I think we likely should revisit a lot of the synchronization, I don't think much of it will be correct.

Remove commented out code from 121 files

54 opened 6 days ago by DanVanAtta

• So many merge conflicts.. Let's get this cruft out of the code base so nobody needs to waste time on it.

Veqryn final cleanup

65 opened 2 hours ago by veqryn

• my preference is for this to go after the commented code removal. There are lot of merge conflicts between the two, easier to do the automated (reformat) stuff after the by-hand stuff (commented code removal).

We had some good conversations going. It would have been nice to capture the details of some of those.

I guess we have the emails for each one so we can work from there?

We have two cases where we have mac only error handling. In one case we kill the game, in the other we ignore. They should be consistent, it's an exceedingly weak argument to suggest that two cosmetic game benefits should have different error handling.

This conversation started in PR #87 where @veqryn suggested we need to see these errors to get users to report them, otherwise they would be unfixed. My difference of opinion is that end users do not need to see errors and a game crash for cosmetic problems, and that we should have mac release testers look for these kinds of issues (which reveals a gap today, for the errors which we print to standard out, we will not be catching these, and we do that quite a lot).

Cool technologies, but they have some big problems:

• serialization means that we don't get compatibility when we do small things such as change names. This is brittle. A dependency on the name of a private variable is effectively making that variable public in scope. This violation of encapsulation is probably largely what makes serialization so brittle. It's even worse than that since the dependency is saved on people's hard drives and remains for months, and cannot be changed in a backwards compatible manner.
• reflection, not only do we lose compatibility between game versions, but we also lose compile time checking that method calls and signatures match, this is brittle

Should we fix? Has this been discuss before? Current thoughts/ideas on how to fix?

We could use a definition for the release process. I'd like to discuss what that process is, we'll document it afterwards.

Below I'll outline a pretty standard release process to start the discussion:

• there is general agreement a current code version of "master" is a release candidate
• next version number is decided
• a branch, referred to as the release branch, named after the version is cut, tagged, and pushed.
• the CI system (or by hand) will deploy the build artifacts to github releases
• testers will DL/install and test:
  -- release bug fixes will get committed to the release branch and cherry-picked into master
• eventually that version is labelled a release version and user migration process begins

The git commands for the new branch and tagging are pretty straight forward:

git checkout -b <new_version>
git tag -a <new_version> -m '<new_version>'
git push origin <new_version>

• I can help do mass file formatting, I'm pretty good with the bash-fu (help is welcome though)
• If we do mass formatting, is their bandwidth to review it? If so, what is testing criteria? Can we skip testing so long as all format actions are done in automated (repeatable ways)?
• If that sounds good, what things should we format?

To start the list of things to format (please comment on additional items to be mass formatted):

• remove license, @author, @version, empty javadoc
• switch to new format style, if we switch (#18)
• add curly braces to all if statements

The following three libraries I think will need to be added very soon:

• guava
• mockito
• hamcrest-all (contains additional hamcrest matchers)

Down the road I think we'll be adding the jars for:

• dagger2
• spock (?)

And of course eventually maven/gradle will be getting this stuff for us, so we won't have the jar file checked in. Till then, wanted to raise this issue, see if there was any objection.

On one individual's computer, a large file is not an issue but when dealing with these file en masse it it burdensome.

Benefits of a smaller file format:

• Fewer server connection used by uploading large files
• Less server side disk space used
• Less likelihood of a connection timeout
  • Fewer connection reattempts
    • Fewer AWS API calls from the server
    • Less AWS S3 disk space used
    • Less AWS bandwidth used

Options:

• MessagePack
• Protocol Buffers
  • Square has a good library for this called Wire
• BSON
• EXI, not really a contender due to lack of well maintained open source library

(oops, didn't mean to close and re-open)

#72 is not complete, I can't re-open it, hence the new issue..

Now that travis CI has access to github, you need to also tell Travis to start doing the builds: https://travis-ci.org/profile/triplea-game (simply a matter of clicking the button towards the center of the page showing a big "X")

Note that my view of that page says admin is needed:

A how-to push release page on the wiki could be useful. Particularly if time goes by and we forget how to do it. Part of the question is, where do we release, and how?

It looks like github-releases is a slick way to go. Keeps us in the git framework. Releases would then be available from: https://github.com/triplea-game/triplea/releases

There should be a way to tag and upload to the github-release. Those steps are what I'm thinking should belong in a wiki.

After that a next step would be to have Travis push automatically for us. PR #58 Adds Travis, these steps look to be roughly what we need to have Travis push builds for us: https://gist.github.com/vinceallenvince/a7611b10f84e61eebdcc

How are we going to build the unstable release artifacts?

The Travis CI release work flow is triggered on tags. I propose we answer the above question above by tagging after we merge into master. If the version number did not increment we delete the current version tag and re-add it to the current commit. In this case artifacts will auto-magically be regenerated. If the version number did change, then we simply add the new tag and again new artifacts will be created.

We previously touched on this topic and found consensus we would like the "m_" and "s_" naming convention dropped. We did not discuss the "I" interface prefix convention, likely this would be dropped as well.

Next on the agenda block is the code formatting. The only remaining convention is then that curly braces are on their own line and to use tabs (announced to gasps and shocks of horror), otherwise the rest are effectively whatever happened to be in the eclipse formater when it was exported. This does create a small problem since multiple developers will not be able to auto-format code in both IDEA and Eclipse and get the same output (so in effect we may get auto-format wars going on).

The goal of this thread is to talk about updating our formatters for consistency. The goal is not to get your favorite formatting idiom in a spec, but more for us to agree on what the format spec should be. That agreement will ideally take the form of perhaps a wiki document that spells out in detail formatting decisions, and/or both eclipse and intelliJ formatters.

I think we have I think these options:

• do nothing, ignore this issue and allow intelliJ formatted code to be different
• spend time building an intelliJ formatter that mirrors the eclipse one
• use a 3rd party formatter that provides both intelliJ and eclipse formatters
• something else that guarntees consistent formatting

My proposal is to solve this would be for the 3rd option, a 3rd party format spec. Reasons:

• they've done the research, decision making, consensus building work for us.
• it's well documented we can arbitrate any formatting dispute (generally things that don't auto-format correctly)
• easy to provide intelliJ people with a formatter, same with eclipse people, adoption of this is easy :) , grab file, commit, then import into IDE
• The google java style spec is detailed: http://google.github.io/styleguide/javaguide.html

So, my question would be - is there agreement that we should try to find and use a 3rd party formatter? This lets us have consistent formatting and agreed upon formatting rules. If so, is google the only 3rd party that gives a formatter and spec? Any objections to going to that format spec?

The how-to-release notes have a mention to download a number of maps to include them in the "maps" folder. This seems a bit hacky since some maps are there, and others are in another location.

I then suggest we do this, create two map folders, "maps" and "maps-extra" (ideally the second would be called extra-maps, but to keep the two folders closer together when sorted, hence: map-extras)

Everything in maps would be packaged in the minimal version, used for engine upgrades and perhaps deployments. The maps-extra would be packaged in the 'all-maps' version and would include everything in 'maps' as well.

This release was particularly confusing with the multiple avenues for bug reports, multiple posts on multiple forums.

We previously discussed migrating from source forge and merging forums. In that context, @veqryn and @ron-murhammer , which forum would you prefer to keep?

I think it's literally that sample. Start with choosing one, then post on the one that is being deprecated that it is going the way of the dodo. Eventually then close the ability to add new posts. IMO we'll bleed over to the one forum for some time and then use the one for a considerable time (months/years)

The grid game code introduces a lot of dependencies into the tripleA code making the tripleA code much harder to work with. This is a big drag on efficiency, and given the features are barely functional and rarely used, I don't think we gain much of anything by having them around (and meanwhile we are committing hara-kiri by keeping this code around).

It's very easy to delete the packages for those three maps. The code update so clients do not freak out about the missing delegates should be mostly straight forward, so this should be feasible and not too much effort.

I've been thinking a dependency injection container would be very helpful. Particularly given all the singletons we have floating around. In triplea-test it was recommended to use Dagger2. So far it looks nicer for us than Spring by being far lighter in weight. I pulled down a Jar file and threw in some annotations, so far so good.

Question then, is everyone good with us using Dagger2 for dependency injection?

I had a very disheartening conversation on the tripleA lobby when discussing a possible feature. The conversation boiled down to no new features because no development capacity (I mentioned this has recently changed!), but more importantly no new features because users leave whenever we release a new update.

Are there any existing or good new ideas of how we can fix this? Namely how we can improve the release process so it is easier. IMO it's a bad path if we lose users on each upgrade.

Now that we have a much better AI, should we remove the half-done, land-only, Dynamix AI?
The main reasons to keep it around would be because maybe some people like playing against it, or maybe Redrum is still using it for inspiration on his own AI.
@ron-murhammer: Redrum, mostly looking for your opinion on this, as you are the official AI guy these days.

Going to Junit 4 + Hamcrest is an obvious improvement.

Using Spock looks interesting, particularly for maybe a functional or acceptance test suite (perhaps a larger scope even if it proves really awesome).

Regardless, what are the current visions for how to improve testing? I'm offering my help, I've a few ideas as well ;)

PS: I started this page to capture a list of test cases we'll want to be sure are captured: https://github.com/triplea-game/triplea/wiki/Some-Things-to-Test-(Functional-Test-List-Plan)

One of the features I really wanted to build was to have a lot fewer clicks in battle. Turns out some time ago by looking at the code, I discovered the features "focus on own casualties" and "confirm enemy casualties." Then it turned out flipping those flags was pretty much exactly what I wanted all along, but I didn't know it was there.

I think we should flip the defaults, so there is by default less battle clicking. It's probably better to have someone play online and not know about this option and have fast battles, than the same person play against the AI locally and wants increased battle confirmations.

It would be great to also find a way to better publicize this option, make it clear what they do as well. Probably that is a more involved effort to group our settings and include a help roll-over. Until then flipping the defaults to faster battles will likely help online lobby users a good bit, particularly new ones.

Just saw a presentation on this format. It's supposedly 100% compatible with XML but it's about 3000% smaller.

It's widely used in industry but not so much with open source projects.

So I think we need to have a little bit of a process around pull request reviewing and assignments.

When you open a pull request please assign it to me. I'll then do an initial review and do 1 of 3 options:

1. Merge the pull request.
2. Add comments on what needs discussed/changed and assign it back to the requester.
3. Assign to Veqryn if I don't feel comfortable with the portion of the code base so he has it in his queue.

Veqryn tends to be the bottleneck since he knows the code base the best so we want to minimize using his time as much as possible which is the reason I'll do an initial review.

Then as they are discussed please assign it back and forth between the reviewer (Veqryn or myself) and requester so that its clear who needs to take action.

This should help to identify who currently needs to take action on the pull requests rather than just having a whole list of them.

I just went through all the pull requests following this process so its clear where things are at.

Thoughts?

Ok, so I do not really know how to use Git all that well.

Questions so far:

1. If I have write permission to the master branch, but I want someone to review my code before I commit it, how should I do this?
2. Branches vs Forking? What is the difference? Which is preferable and when to use each? And how do I keep my local branch or local fork up to date with the master?
3. When using branches, after your pull request gets accepted and merged, you want to code a new feature or something else. What should you do? Is it preferable to throw away the branch and start a new branch based off master? Or should you pull master into your branch and merge it, then code from there?
4. How do I commit things under a different username/email than what my global git settings say. No, I don't want to change my git config, because I really do have multiple users (one for work, one for personal).

Any other tips are appreciated.

Any guidelines or best practices for using and working with a wiki? Second, given our current wiki, how are the pages coming up? I think the github workflow page could use some work to simplify it a bit, make it a cleaner to follow.

Are we needing any other important pages?

To start the conversation with my thoughts, please speak if you have a different viewpoint:
I think the wiki is good for:

• capturing code documentation "stuff" (descriptions of how to build, how to deploy, etc)
• great place for organizing and summarizing results of discussions that occurred in github issues.
• capturing decisions made

I do not think a wiki is good for:

• documenting the process of making a decisions, all the events and process and considerations, needs to be a summary thing
• not good for paragraphs of text, bullet points are good

Some best practices:

• do edit pages other people have created, seek that edits are always improvements
• do not get into edit wars, original author can revert edits, but before changing something back, always contact author
• favor using tables! It's easy to extend tables with more data, both more dimensions (columns) or more data points (rows).

It's probably useful to have a list of items that have been identified as things to work on. I found the source forge ticket queue useful for giving some direction for some things to fix.

So, question: how are we going to track the existence of things we want to do, improve, fix, add, etc? Secondly, any thoughts how we will administer that list?

Map parse errors on load should be quietly logged (ie: logged to console in background but not shown to the user). For this issue, make that change, and also add an option to the game (default to off) where all such messages can instead be logged to standard error instead of standard out (which brings the console window to the foreground with the error message). This will be a useful option to be set to "on" for map makers and developers.

Scenario:

• User downloads a map
• We delete the map and the delegates
• User then upgrades game engine

Defect:

• On game launch the user sees an error message about delegate not found and a stack trace. Note, the map they downloaded is still in their home folder triplea/maps, so it was never deleted even if the map doesn't come with the game engine anymore.

Problem:

• We cannot delete maps in arbitrary locations on update, and the error message is completely raw and will be nonsensical to users.

Expected Behavior:

• Quietly log the warning in the background with a future option for beta testers to always see this.

Work-around:

• Delete the map

Best fix:

• We figure out if we should support the map. If the map is bad we ask user if they want to delete it, otherwise ignore it. It is a map for an older version. Last, we create a way to clean up old maps.

Can we up the source compatibility to 1.7? What do you guys think. Given that Java 7 is no longer supported one could even argue that even going to 1.8 is valid.

A conversation around this question asked from another thread:
@djensen47
"What are the different types of issue tags that we need in order to organize the types of issues, discussions, questions, and whatever else we anticipate."

• Update Version Number
• Branching and Tagging
• Building Artifacts
• Upload Artifacts
• Release Testing
• Forum post and latest_version.properties
• Update website and lobby
• Update Lobby Bots and Lobby
• Update Desura and Partners

@ron-murhammer @veqryn
I broke up the how to release page (http://github.com/triplea-game/triplea/wiki/How-To-Release) into smaller pages, idea being to make the steps a bit more bite sized. As an added benefit it makes a convenient check list. Please run with this idea if you like it, but I think it would be good to create a ticket for when we do releases and include the check list in it. As we automate, the check list will become smaller. The check list should help ensure we do the process completely and correctly, but will also help keep everyone on board with where we are with the release.

@ron-murhammer , since this would impact you most immediately, if you do not want to do this, simply close this ticket...

https://reviewable.io/ offers a better visualization of pull requests, we should add it to our system.

for example usage see for example gradle/gradle#490, notice the automatically added review on reviewable button

We have a Travis CI file in our build. It works and has been building in my local repo: https://travis-ci.org/DanVanAtta/triplea, I'm already at build 41.

All we need to do for Travis CI to build triplea-game is to grant it access and then click a button on the travis CI web UI to turn builds on. So this all a simply a matter of clicking yes, all configuration is done and already pushed into master.

@veqryn and @ron-murhammer , could you please find the email and grant access (should be dated Aug 7th)?

After we get Travis CI permissions, and turning build son, any branch with the .travis.yml file will automatically be built (compiled and tests run). Later Travis CI can be updated to do more, like create and push releases when we want it to.

I've looked over creating OS dependent packages. Given that with the Gradle system will need to restart this issue mostly from scratch I decided to revisit the problem at hand.

At the moment from my understanding we use:

• NSIS for Windows
• manually hacked together ant task to create the dmg file for MAC
• no installer for Linux, package maintainers do this (there are PPAs for Debian, and ArchLinux has its own https://aur.archlinux.org/packages/triplea/)

I've researched the subject somehow, the better ways of doing this is:

• izpack - free, no real Gradle support :(, other than that seems solid, although hard to configure
• launch4j - (as I understand generating the packages on latest Linux is troublesome) not that fancy as izpack, otherwise no problem.
• install builder this seems the most professional execution, features, although not open source. It also allows auto update of the application (something we talked in another issue). It's quite pricey but they do offer open source licenses, we should try to apply for one. With this it's possible to generate the installers from any system to any system If I got this right.

I tend to opt for the 3rd as it provides the most polished result with the least effort. So what do you guys think?

Thanks,

This dovetails with CI, so despite my preference to leave this for another day... I'm bringing it up, particularly since we already broached on the topic.

Now that we'll be looking to be build "unstables", the work flow would be to increment and tag after merging to master. This will create a series of artifacts that are automatically pushed into github. From there, at any time we can then choose to do release/best testing.

With the current release number scheme: https://github.com/triplea-game/triplea/wiki/Release-Version-Numbers, we would be re-using the same number. This loses the track record, and is a bit of an anti-pattern for version numbers, which are supposed to increment on change.

Our last release number as an example: 1.8.0.7
The 1 and 0 spots are not very well used, particularly the 1. We are also missing a spot to be able to increment different unstable versions. So my proposal is we remove the 1 and 0 spots, and add a new spot to the right for a build number.

So the current stable version would be:8.7.0
The next unstable would be: 8.7.1
The next stable that is still save game compatible would be 8.8.0

The next unstable that is not save game compatible would be 9.0.1
The next version that is not save game compatible would be: 9.1.0

I've got a couple of eclipse launchers with args to launch the game and the headless server, and a third for running tests. It's preferable I think to have these files checked in, easier than giving details of how to set them up. Also when I clean my environment it's one way I can see to make set up time easier and more efficient.

Questions:

• Any objections to these launcher files being checked in?
• To the intelliJ users, can intelliJ piggyback on the eclipse launchers, or do we need versions for intelliJ?
• Any suggestions for good folder structures to hold these files?