The changes in master over 3.3.0-beta3 right now are few and limited in scope. I’m reasonably confident that we won’t get bug reports because of them, and that we won’t get many additional bug reports from anything else new which has already appeared in a beta.
I think it’s quite possible that we would get a lot of bug reports due to the changes which have open PRs right now—not because I think they’re incorrect, but because they’re the sorts of changes which affect modules, saves, and logs, which makes it more likely that there are effects we haven’t anticipated.
So:
- I would like to release beta4 roughly as master is now.
- I would like to release 3.3.0 from that if there aren’t any new issues introduced in beta4.
That will get all of the fixes which are already done and have had some user testing out to users. No one will be worse off for not having the bug fixes which are in PR now, as they deal with preexisting bugs. Then we can put these new fixes into 3.3.1.
Related thing:
We’ve put the Subversion version number into builds the entire time we’ve been using Subversion. On switching to Git, we no longer have an increasing version number we can use for that, because Git commits are SHA1 hashes and are effectively random. However, “git describe --tags” can produce a version string which consists of the most recent tag reachable on a branch, the number of commits beyond that tag, and the commit hash. E.g., when I run that on master right now I get “3.3.0-beta3-80-gf8ef2523”. The “80” means that we’re 80 commits ahead of 3.3.0-beta3. That’s basically a build number, and we could use it that way for naming builds.
If that sounds reasonable to everyone, I’ll update the version string parser to handle these.
Thoughts?
I know I’m new here but being a strong proponent of CI/CD and every single commit leading to a deployable release, yes sure, release 3.3.0 and let’s get working on 3.3.1. The main changes that led to the new 3.3 minor version are already in anyways, the rest is “minor” and backwards compatible and can go into the x.x.1 patch version.
Since I love the idea of continuing minor patches and improvements to the 3.3 line (hoping to get that html chatter in!) this seems like a positive approach to me. When I started doing Vassal back in November the whole developer side seemed super quiet and inactive - so it has been awesome and refreshing to see so much going on and so many good fixes these days.
Also Joel I have several bugs currently “locked in moderation” including one Brent asked me to write up. They are 12551, 12980, 13014.
It would be lovely if you could unlock them so they are at least visible to others.
Have you guys considered a permission setting for known-advanced-users who aren’t full dev team members but could e.g. file bugs w/o moderation? Heck for a whitelist through content moderation I’d probably pay a subscription fee! ![;)]( "Wink")
Brian
Sounds good to me Joel. I
Is the core concern around people using custom classes?
If so, is there any way module makers could be encouraged to describe why they needed custom classes and try to introduce them into the native app as features?
Or is the concern around beanshell scripts?
Nah, I was just trying to understand what parts of the changes during the beta are the most risky.
The changes included up to now have been very neutral. e.g. the HiDPI fixes that fix display issues. Nothing that could cause changes to the behaviour of units in a game. I think Joel just wants to get those out the door before starting on a round of significant bug fixes that have a lot more scope for causing problems and will require extensive testing.
Fair enough, thanks for taking the time to explain.