3.3.3 release plan

[uckelman]

I've uploaded a current build of master, VASSAL-3.3.3-SNAPSHOT-82454de2. (NB: builds will have "SNAPSHOT" in them from here on, as this is how Maven wants to do it. That seems fine, as it makes clear what the test builds are.)

http://www.vassalengine.org/~uckelman/tmp/

I'm aiming to plow through the remaining PRs up to the HTML Chatter one in the next day or two, and at that point I think were ready for a beta?

We have a rather large list of items in the change log this time. Some aren't things which will interest anyone (e.g., 13164), while some will interest only people who were having the bug which is corrected. The items which add features aren't a great way to tell anyone about the features---at least not in my experience---but I'm not sure what we could do that's better. Ideas?

[Cattlesquat]

I could probably put together a little "brochure about the new features" with some of the little screenies I've been decorating the PR's with. End up with a fun little post to put, I don't know, in the Module Design forum, and I guess maybe link it or put some of it in the launch announcement in the general forums?

OR, I could "serialize it" as a series of forum messages and/or wiki articles, "one per feature". Just depending. You can tell I've put about 1 minute of thought into this so far, but I'm certain I could haul together something "nice" one way or the other.

Which reminds me, as I'm going through the online documentation here I'm looking for a good place to include documentation on the fun stuff about how the Chatter works now and how to take advantage of it. But a little infelicity is that since the Chatter isn't a visible/configurable "component" (i.e. in the Editor), it doesn't have a logical "Help" article hook. So if anyone has any good ideas, by all means speak up.

I'm assuming we'll try to push through at least one wave of documentation improvements before we launch a 3.3.3 beta? Should probably only take me a few more days to have a first pass done. I'm up to "M", and I got through "Map.Htm" tonight which just about killed me but it's beautiful now

Brian

[Flint1b]

Separate the list of new features from the list of fixes. If there is many new features, separate them further into categories. Always put new features at the top, fixes at the bottom.

Examples:
- https://wiki.factorio.com/Version_history/0.18.0
- https://feedback.minecraft.net/hc/en-us ... er-Release
- https://eu4.paradoxwikis.com/Patch_1.30.X

[uckelman]

Thus spake Flint1b:
> Separate the list of new features from the list of fixes. If there is
> many new features, separate them further into categories. Always put new
> features at the top, fixes at the bottom.

I used to do that. I got the impression that it didn't make much
difference.

--
J.

[Flint1b]

I used to do that. I got the impression that it didn't make much difference.

Well it's how most games do this, and these examples are not just any games, this is Minecraft and two of the top sellers at Steam. And they are even similar to Vassal, they offer modding support and usually have special sections in their changelogs for modders. We could have special sections for module designers.

Also, we could replace our technical bug descriptions with something more user-friendly, "Undo bug: fix all reproducible cases of the nasty infamous undo bug" sounds much better than "Undo bug: don't add pieces to DragBuffer"

[Cattlesquat]

Separating features from bug fixes is certainly a "best practice".

[m3tan]

Is there any WIP list of new features? Bug fixes seem to be documented much more just by thread discussion. I already noticed a band-select option for Does Not Stack. I'm wondering what other easter eggs are out there...

[uckelman]

Thus spake m3tan:
> Is there any WIP list of features and bug fixes? I already noticed a
> band-select option for Does Not Stack. I'm wondering what other easter
> eggs are out there...

CHANGES contains a list of issues we've already completed:

https://github.com/vassalengine/vassal/ ... er/CHANGES

You can see issues which are in progress in the PR list:

https://github.com/vassalengine/vassal/pulls

--
J.

[m3tan]

Thx. I knew it existed somewhere.

[Cattlesquat]

If you go to that "pulls" link, you can also click the "Closed" PR's tab and then sort it by "Recently Updated", and it will show you things that have been merged into master. The ones with "issue numbers" by them are more likely to have features in them as opposed to refactoring and cleanup. Clicking into one you can often find more detail than the changelist. Etc.

Also by "number of comments" you can find the real dumpster fires

[Flint1b]

Is there any WIP list of new features? Bug fixes seem to be documented much more just by thread discussion. I already noticed a band-select option for Does Not Stack. I'm wondering what other easter eggs are out there...

A ton of new features are refactorings, build process improvements, code quality improvements, compile warnings, code formatting, removal of old/dead/deprecated code, we are moving mountains behind the curtain, this has no effect for users and module designers, and is not documented anywhere except in the commits and commit messages

Edit: actually, there's a very neat thing for module developers, a Vassal dependency that can be pulled in by Maven, we already released an alpha version of that and I started a template module.

[uckelman]

Thus spake Cattlesquat:
> I could probably put together a little "brochure about the new features"
> with some of the little screenies I've been decorating the PR's with.
> End up with a fun little post to put, I don't know, in the Module Design
> forum, and I guess maybe link it or put some of it in the launch
> announcement in the general forums?

We do need something describing at least the new features in enough detail
that people who are interested can discover what they are.

--
J.

[tinjaw]

Why not tag it for maketing reasons as a "Developer's Release" and say that all the improvements are there to make the lives of VASSAL developer easier. User-centric improvements will be coming in the next release. The add a paragraph that says, if you are a geek and interested use this filtered URL for more info.

[uckelman]

Thus spake tinjaw via messages:
> Why not tag it for maketing reasons as a "Developer's Release" and say
> that all the improvements are there to make the lives of VASSAL
> developer easier. User-centric improvements will be coming in the next
> release. The add a paragraph that says, if you are a geek and interested
> use this filtered URL for more info.

Because that wouldn't be accurate. I count one of 40 items in the change
log right now which is neither a bug fix nor user-facing.

--
J.

[Flint1b]

Most of the stuff I contributed was development-centric and had no ticket in the tracker and doesn't show up in any changelog.

Normally, management would have me executed for that