Release: 1.8.0.7 about triplea HOT 14 CLOSED

Yes, some things are blocking us. I'll try to take care of it this weekend.

from triplea.

Some more questions about this release.

• Is this the last one before we use gradle?
• is this the last one before we start releasing to github-releases
• do we make in the installer on next release

Another set of questions:

• What is the feature list of this release? Perhaps worthy of another issue, how do keep track of the feature list of releases?
• If the feature list is not so small, is it worth the user pain of upgrading to a new release?
• We'll be increasing the size of the download with another "old" jar - can we remove some of the older ones to help with the DL size?

from triplea.

1. Depends on how gradle progresses. But generally we've been doing 1 major stable release per 6-12 months, so I think that is more than enough time to get gradle working.
2. Github does not handle our releases, they do not provide a file hosting service that accommodates the 1-2gb we need per release.
3. ?
4. That is something I generally have been putting together each release based on the changelog and what commits have been made. Redrum will do it this time. For examples, look at our past releases in the forum, there is a thread dedicated to each release.
5. Yes it is, it has been a year and the AI is miles ahead of the last one.
6. No we won't need to add another 'old' jar, because 1.8.0.7 can open any other 1.8.0.x savegame. That is how our versioning works. Savegame compatibility is only broken when we change the first 3 numbers, not the last. As far as removing the old jars go, I have basically decided that we should be keeping the last 4 major releases that had incompatible savegames.

from triplea.

1. If next release is going to be with gradle, that is probably a month out or more. Let's stop blocking stuff for the release then. If also the next release after this one is going to be a year or more away, then let's accumulate more features over the next few weeks first while there is momentum for adding them.
2. We don't have release files over 2GB in size, we can host multiple files that sum to over 2GB:
   From: https://help.github.com/articles/about-releases/

We don't limit the total size of your binary release files, nor the bandwidth used to deliver them. However, each individual file must be under 2GB in size.

I think this may be one of those last long-lost topics in triplea-test that was discussed. We had some discussion of alternatives, like I think for example using bitbucket. Github-releases was the general target of something to look at and the tool that was most likely to be used.
3. @gaborbernat is looking into updating the installer, see #13 and #31
4. Understood. I recommend we have each commit author add notes to a wiki after PR merges. We can then have someone else summarize this list for general consumption, or give a link directly to it. The link directly to it is least overhead, so I like that. Also it allows users see what features are coming up in the next releases, which is good transparency and can build some enthusiasm for releases. Such a list would also be useful for answering questions such as number five.
5. If we want to release "now" we should go with the old ant way.
6. Please document how versions are numbered or send a link, I do not recall seeing it anywhere. Now that so much time has passed since v1.5 has ever been used (v1.6 even), removing those JARs would help on the DL size. The time between releases should be a consideration for how many to keep.

edit Did just notice that you said "major" stable release. More clarification on what is intended by a major vs a minor release would be helpful.

from triplea.

Another question, per #6, the next release is officially dropping java 6 support?

If so, we can remove interesting stuff like this: (ClassLoaderUtil.java, use reflection to call close method on the parameter, Java7+ dependent, silently ignores errors):

  public static void closeLoader(final URLClassLoader loader) {
    try {
      try {
        // java 1.7 has a close method, thanks guys
        final Method close = loader.getClass().getMethod("close");
        close.invoke(loader);
        return;
      } catch (final Exception e) {
        // ignore
      }
      releaseLoader(loader);
    } catch (final Exception e) {
      e.printStackTrace(System.out);
    }
  }

from triplea.

We MUST support java 6 fully until our mac release fully works with java 7/8.

from triplea.

Is it possible we'll do a gradle release if that were not the case? Asked in another way, isn't part of getting gradle done (#31) to get it to build mac installers that work for Java 7/8?

Do you have objections if we start keeping track of release notes with wiki pages rather than doing it all at once at the end?

Since github releases can support our build artifacts, are we going to transition to it sooner or later? Alternatively is there new disagreement to use github releases?

from triplea.

@DanVanAtta I think the idea is to do a release in the next week or 2 based on the existing ant build and current code with Java 6 support still (1.8.0.7). After that release then we can look to finish the gradle build, upgrade to Java 7/8, start to define a new build/release process, and merge in lots of changes and look to eventually release a 1.9.x.x in say a few months.

So release notes right now are kept in the changelog.txt and should be updated as features/fixes are being made but I was lazy and didn't keep it updated. We could move that to the wiki if you think that would help but I think the issue is mostly remembering to update it not where its located.

from triplea.

I prefer the changelog to still be updated.
Release notes do not need a wiki. They are just taking whatever is in the changelog and putting it in nice human readable sentences, the day you release (and then posting it to the 4 or so different website forums we have a presence on, in a post similar to what i've been doing).

from triplea.

agree with @ron-murhammer and @veqryn, definitely plan to fix all Gradle/installer issues during the next month.

from triplea.

The change log has problems, notably it is a source of merge conflicts. For example, work on two features at the same time and already you will have a conflict. Let alone the consideration of other people updating it as they work on things.

Also, it'll be a source of needless pull requests for cosmetic/typo correction type of changes to that file.

Last, reviewing changes to the change log is not a good thing to loop into all code reviews. The overhead of a round trip of communication of a reviewer asking anything about the change log, could really slow things down. Like for example, I review and say, hey, this all looks good, but you forgot to add your 4th feature to the change log. A day goes by, or two, the other person checks mail, oh okay, does stuff... 20 minutes later it is updated. Time goes by, reviewer merges... The time of the round trip in communication is days, and is largely waste. To boot, in this scenario wiht a wiki the reviewer could just add the 4th note on the spot, merge it and say "by the way, you forgot the 4th item, i went ahead and added it, or alternatively, I merged but notice in our wiki you are missing an item, please add it."

A changelog in version control only makes sense to me if we will present it to the user. I think it would be good for us to move in a direction where there is a change log menu item, or in the about tripleA we show the change log.

To fix the merge conflict problem, you use a wiki. The wiki mirrors the change log, then when a release is done, the release person copy pastes the latest from the wiki into version control and commits it. The wiki then lets a whole lot of micro-edits happen without the overhead of pull request, and we can keep our code reviews more focused on code (and avoid those unnecessary merge conflicts)

edit updated a bit for clarity

from triplea.

The changelog is just a single line item per decently sized feature / bug fix (we didn't put any change log items in for all these formatting & comment changes, on purpose because they are too small to matter).
If we have merge conflicts, you just move one of them up or down.
Seriously, this is NOT an issue.

from triplea.

Understood why we have it and what goes in. But it is an issue if you can't just update it.

For example, the change log is currently not correct since it doesn't have the features I added. Secondly, I need to submit a pull request now to add in notes about those features. Examples of actual problems that exist today.

This is a bit of a broken process for those that can't just push. I do not control when merges happen and can never know which version something will be released under. Not all edits will also be adding in just one line, some changes may be more detailed, and sometimes we may go back and revise the notes to clarify or add in detail perhaps. We also have possibilities for more complex merges given the number of in-flight branches and sources of changes, namely a 3 way merge or more complicated. Picture one branch that has added 2 lines, another that has added 3 and fixed up 1, and another that changes the version number and that is the one pushed first. It's a lot of merge conflict work to re-order and also move stuff to the right version number...

As mentioned, we pollute our commit history, small changes to this file necessary by process end up having way more overhead than they should have.

Perhaps consider yourself submitting a PR to change this file. Picture you have a typo in a line or something. The overhead of that seems silly, I don't think you would ever do that PR, and nobody else should have to either.

from triplea.

• I've objection to the change log implementation as already described in far too much detail, but I'd rather drop it and keep the current convention in favor of concentrating on other more important goals

With that resolved, I don't think there is much left to discuss or track in this issue.

from triplea.