I'll just respond to your first post for now since I started my reply earlier today.
illwieckz wrote:Is a future map-plat23_1.0.pk3 will supersede map-plat23_b13+1.pk3, unless b13+1 > 1.0 on a “sort” side ?
According to the debian versioning scheme we use, letters should be greater/newer than numbers, which is why I'd recommend r01
(for "Release") for the final version of maps that used a
before. Whether a letter/revision or floating point version (or anything else) is used is up to the mapper, which is why we use the +n
standard to make updates (or, to prevent clashes when more people are likely to make updates +year-month-day-time-name
. You can find the official versioning guidelines here
illwieckz wrote:Some maps from Tremulous were previously versioned _trem, for exemple : map-orion_trem+2.pk3.
So, when I updated them, I just increased the number, for example map-orion_trem+3.pk3, keeping the _trem part since trem is a very high “number”.
That (using _trem
) was actually a bad idea as it interfers greatly with the author's versioning scheme. A +
notation should've been used. I'll discuss its format at the end of my reply.
illwieckz wrote:So, for maps that already have this versioning, it's too late since some servers and players already uses it
True in theory but I'd rather refer to our alpha status and give even existing maps a proper version. The client would load the same map as is loaded on the server anyway, only for a local game it may be that an outdated map is loaded.
illwieckz wrote:What do you think about using a trem- prefix while naming maps from Tremulous? … For example, the map map-vega-beta1.pk3 from tremulous can be named map-trem-vega_b1.pk3, and in server list, called trem-vega, so the user knows he is voting for a trem map.
Just to be precise, the prefix must be map-
, the engine expects it that way. Using map-trem-
as a prefix works, technically, but it means that "trem-" is part of the map name. This is neither true nor the standard and it also requires you to rename the BSP and other files and folders to match. The "trem" (or "unv") bit should be part of the version, not of the map name!
illwieckz wrote:If the mapper wants to update it officially for Unvanquished, the new one will be named map-vega_1.0.pk3 for example, so there will be no conflict between the map I ported, and the map he improves, even if the version number of the ported map is higher than the version number of his official release for Unvanquished.
If the mapper updates the map, they would choose a higher base version anyway or just increment the version extension. This in comination with us using a +
notation as explained below makes sure that "the version number of the ported map" can never be higher than "the version number of [their] official release for Unvanquished".
The idea is to define good practices now to prevent future mess, before more people try to port and create unofficial maps for Unvanquished.
OK, so let's get to my versioning proposal, which should be in line with our official guidelines.
First of all, I think as the map version is an Unvanquished-specific version, the version string shouldn't include "trem" but "unv". It is also clear that we should not touch the author's (base) version but release an update to that version via a +
notation. Let's say the original map is map-vega_1.0.pk3
, then we now have that the new version should be of the form map-vega_1.0+…unv….pk3
So let's talk about that suffix. We could go with a simple iterator, e.g. unv1
, but that has some drawbacks. For example, you don't know how old the release is (and whether it is likely to be outdated) and, secondly, this only works if you have a single porter, which may not be the case in the future. My proposal for the prefix is unv-unvversion-portername
. This is a tad less precise as the date/time format we use for development packages but it's easy to read and will show you in an instant how old the port is, which is important given that every Unvanquished release may break with the old map requirements. Including the name of the porter ensures that two people can make a port for the same Unvanquished version independently. For the name of the porter, to go in line with the other guidelines, only lowerspace letters and numbers are allowed and it should be shortened for long user names. The Unvanquished version should be of the form a27
for Alpha releases (0.27.x, the x is only used for hotfixes that won't break the map format) and b01
for Beta releases. (Note that I plan to use b01
as the version for the first beta release we make as we can't really increase the first 0
To put this together, if you're working on a port that would work with the current Unvanquished version of let's say 0.30.1, you would turn map-vega_1.0.pk3
. You wouldn't need to update the a30
when Unvanquished 0.31.0 is released since that string is just a measurement of the age of the port, measured in Unvanquished releases. If you want to make a new release for the same Unvanquished release, you would append a simple iterator: map-vega_1.0+unv-a30-illwieckz+1.pk3
So, that's my proposal. In addition to being relatively short compared to the date/time/author format we use for development packs, it means that a server admin could either decide to only ship the ports of a specific porter or, in case they don't have a preference, they'd always use the latest port which is a good default behaviour.