I worked with a major developer that used a 4 digit schema
major.minor.maintenance.internalbuild
Most things I encounter these days use something compatible with Semantic Versioning for their version number format, which is three dot-separated decimals (x.y.z) followed by optional prerelease and build tags.
New modules uploaded to the module library will be required to follow that version number format.
2 Likes
Thatās what I was wondering about. Thanks, bookmarked.
Hi there,
As I see it, there are at least three distinct āversionsā that each game could be dealing with
- The game edition. For example, The Russian Campaign comes in five editions.
- Module variants. A module may come in different variants, for example by different implementations (for the same or different game editions, or even covering multiple editions - e.g., my Napoleon at Waterloo module). There are, for example, four distinct implementations of Afrika Korps. Some implementations may even give more variants - e.g., my version of Afrika Korps comes in two variants - a colourful variant and an olā-school variant.
- Module versions. Each individual module implementation can come in various versions (which is what was discussed above).
It is not clear to me how you plan - if at all - to accommodate this different āversionsā. Could you say a little about that? Thanks.
Yours,
Christian
Iām going to use the phrase āsame moduleā in reply without defining it but in the expectation that there is agreement on what counts as same in the vast majority of cases.
Packages are intended to contain one or more versions of the same module. Projects are intended to contain related packages maintained by the same owners.
So:
-
If there are multiple distinct modules for a game with different maintainers, each such module should have its own project page.
-
If there are multiple version of the same module, those should be grouped together in one package.
-
If there are variants of the same module with the same maintainers (e.g., a separate two-player and 3-5 player version), those should be in different packages in the same project.
That said, Iām not aiming to split up pages where multiple modules have been mashed together as part of the migration from the old module library to the new. Thatās something which can happen later.
2 Likes
Hi Joel,
One way to define āsame moduleā would be to say it is the āsame gameā, which if course is largely semantics because begs the questions of what is the āsame gameā 
One way to define āsame gameā would be to say that a game is defined by its BGG entry. Thus the three first editions of The Russian Campaign are the same while the 4th and 5th editions are both separate and distinct games.
Same with D-Day - 1st and 2nd editions are the same, while the 3rd edition is a separate game (incidently, the VASSAL modules comes in 2nd and 3rd edition, with a tournament variant of the 2nd edition too).
However, all three editions of Afrika Korps would be consider the same game, even though the rules where revised a lot between the three editions.
Another way to define āsame gameā would be to say they share the title, but that seems a little vague.
OK, just to make sure I understand what you say. Let me take an example to illustrate and see if I got it right.
Afrika Korps has several modules
- By Wargame Academy with versions
- 2.3.1
- 2.3
- 2.2.2
- By Allan Dickerson, et al with versions
- 1.1
- By Charles McLellan, et al with versions
- 1.0
- 1.1.1
- By Christian Holm Christensen (me ) with versions
- 1.1-ch
- 2.0-ch
- 2.1-ch
Each of these versions a available in two variants - Normal (colourful counters and board)
- Olā-school (NATO hostile and friendly colours)
As I read what you say above, we will the projects
- Afrika Korps by Wargame Academy, with one package having versions 2.2.2, 2.3, and 2.3.1
- Afrika Korps by Allan Dickerson et al with one package with version 1.1
- Afrika Korps by Charles McLellan et al with one package with versions 1.0 and 1.1.1
- Afrika Korps by Christian Holm Christensen with two packages
- Colourful
- Olā-school
Both packages will have versions 1.1, 2.0, 2.1
Is that correctly understood?
If so, how will this be presented to the user?
In the current draft GLS, the user is presented with a single page with one project. Will the user still be presented with one page but with multiple projects? Or will each project have its own page?
That is, if the user searches for Afrika Korps, will the user see one entry or four entries, corresponding to the outlined projects?
If it is the latter, what titles will the user see? And is the game meta information (publisher, year, era, # players, description, etc.) be shared between the projects of be individual for each project?
Also, some module pages has additional stuff beyond the modules, saves, and logs. Afrika Korps for example has a ZIP archive of āSupporting materialsā. Where will that go? As a separate project, or with the Game meta information?
Also, Iām not sure how you will handle different editions of a game implemented (e.g., the five editions of The Russian Campaign - will they be five different packages with in the same project, or will they be five different projects? If the user searches for The Russian Campaign what options will be shown?
Thank you for making these things clear to me.
Yours,
Christian
Yes, thatās right.
What do you suggest?
Presently, the game data is independent by project.
My thought is that it depends on what the maintainers of the projects decide to do.
1 Like
OK, thanks.
I think it largely comes down to what āsame moduleā/āsame gameā will be taken to mean. For the sake of the argument, and what I would advocate, is āsame moduleā/āsame gameā corresponds to the BGG division. I will call this a game here.
Aside:
If the API of BGG is open, then the GLS database could contain a field that references the BGG game identifier, and meta information about the game could be retrieved using that API. This would add the benefit that the GLS can get complexity (BGG lingo āweightā) ratings, and so on. Of course, it creates a tight link between the VASSAL GLS and BGG.
OK, so with that assumption, I would say that each game should be presented to the user. Thus, when a user searches for Afrika Korps then a single entry will be shown that has all āAfrika Korpsā projects in a single page. When a user searches for D-Day, then the user will see three pages
- D-Day
- D-Day (3rd ed.)
- D-Day - Smithsonian
A-side:
Searching for D-Day does not currently work - the dash (-) is somehow interpreted as an option on the server-side, which indicates a possible arbitrary code execution on the server.
If the user clicks a project, then the user might be taken to a separate page for that project which could contain more information. This would probably necessitate that each project has both a summary (shown on the game page) and description (shown on project page) field.
In some sense, the question is if the user will do a game or a project search. Both could be possible of course.
A-side:
The current sort order of search results is a bit funny. If you search for Afrika Korps - with the correct German spelling and a complete match - the first entry returned is North Africa:Afrika Korps vs Desert Rats, 1940-42 - even if the sort order is set to Relevance. An even worse example is searching for Battle of the Bulge.
Presenting a single page with a list of projects for each game will also allow auxiliary stuff to be posted as a separate (non-module) project.
Other question:
- How are new game and project entries created? Are these done by the administrators, or will it be open to users?
- Who will be allowed to edit game stuff? Clearly, project developers can edit their stuff, but what about a level up?
OK, which I think is best dealt with with a single game page.
Perhaps game entries should not only have a description field but also a summary field that could be shown on a search.
I think you, as administrators, have to come up with a policy. I think it goes back the to understanding of āsame moduleā/āsame gameā. If you adopt the same division as BGG - as argued above, then developers will need to attach their project to a game. I think this is what you, Joel, recently also argued for in another thread. Of course,this does not need to be rigorously enforced, but there should be good arguments for doing something different. But I think it begs a number of questions like who can do what and so on.
Thanks again.
Yours,
Christian
Thanks for spotting this. There was no SQL injection vulnerability, as the query was being properly quoted as SQL. What was incorrect was that the query string is parsed by sqliteās FTS5 module as a query expression when what we actually want is for the query to be interpreted as a phrase. This is fixed now.