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.)
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?
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
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.
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.
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”
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…
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:
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
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.
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.
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.
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.
Okay here are the remaining items from my “documentation sprint” that I would ideally get done in time for 3.3.3, in rough order of my current prioritization:
(1) [DONE] All screenshots that needed updating because of 3.3.3
(2) [DONE] Full “edit pass” on existing articles; many articles expanded
(3) [DONE] Basic alphabetical Table-of-Contents of subcomponents for Module, Map, and Game Piece pages
(4) [DONE] HTML Chatter documentation - own article, plus mentions in Report Action, Message Format, and Module articles.
(5) Finish my half-done “Toolbar” article (Mommy, where do buttons on the Toolbar come from?)
(6) Updates to Expression & Property Match Expression articles to account for Brent’s latest improvements.
(7) “New Features List” per above, for announcement of the various designer-facing and player-facing improvements in 3.3.3
(8) If there’s time, I’ll start getting together a little “quick links” navigatio section to go on the bottom of every page.
It’s not that many more days of work. Of course as soon as I see the Chatter get merged I’m gonna be going “crap! crap! crap!” and trying to get it all typed in quick
Stuff that could fall “below the line” but I could do sooner if desired:
(9) A decent “Landing Page” for the online Help – something that helps you Browse Your Way To Goodness.
(10) Remove the Editor’s “Help” link that leads to the PDF file and point it at the new Landing Page (small code change)
(11) A pass through the UI (i.e. code) to consistently refer to “Key Command” rather than e.g. “Keystroke”, “Keyboard command”, “Keyboard shortcut”, “Shortcut”, etc, etc, etc. Obviously “Hotkey” is still a qualitatively Different Thing. Obviously this would also involve re-taking a bunch of screenshots, lucky me. But I’ve definitely got THAT down to a science now.
Does it make sense to pick some date in the near future and aim for that as “beta 1 date” as a kind of “milestone”? Friday? Next Monday? Some other day?
Let’s do it like other modern projects and bring out a beta every week, or every other week or something like that. Rolling releases. Whatever gets merged until then gets into the beta.
And for the hardcore Vassal enthusiasts, a nightly build every day. @Joel do you think you could automate the build so we can give it to Travis’es naked ubuntu, have it download all prerequisites and run the full release build? Shouldn’t be too much left, we already have automated JDK download, some of the tools can be installed by ubuntu’s apt, just these exotic ones that need to be compiled manually seem tricky but it’s no rocket science to setup an ubuntu to build C stuff. Then we’d have to handle automatic versioning, tagging and deployment of the built packages, shouldn’t be too complicated.
Does it make sense to pick some date in the near future and aim for that
as “beta 1 date” as a kind of “milestone”? Friday? Next Monday? Some
other day?
I see two PRs which should still be merged—the ones for 13129. I’ve
been trying to plow through my message backlog this evening rather
than tend to PRs. If you’re satisfied with those two, I’ll get them
merged soonish.
Do the docs actually need to be updated for beta1?
I’m expecting that with this quantity of changes, we’ll have a period of
fixing bugs between beta1 and the subsequent release, and even if there
aren’t bug reports we need to have beta1 out for at least 10 days to
afford sufficient opportunity to try it. So I expect that you’ll have
ample time to finish the doc update before 3.3.3 even if you’re not done
by the time we put out beta1.
Does that sound ok? If so, we can release beta1 once those two PRs are
merged, maybe tomorrow evening? Or would you prefer to have the updated
docs go out with it?
Okay yeah, if we’re okay with some docs getting finished up during beta then we’re probably getting close to a point that we could pull the trigger. Give me an “aim point” date for beta 1 and I’ll try to have things at least be “clean” by then. And I’ll also try to get a “new feature page” together though again that can improve over several betas.
