I believe that QGIS 3.0 and QGIS 3.2 are essentially the same series. QGIS 3.4 comes out 26/10/2018 and also belongs in the same series.
Additionally, a lot of plugins and features are being ported to the new versions. I believe our energy would be best used to try and optimise the latest release.
I believe only 2 tags are needed going forwards: qgis-2 and ...
I would argue that pyqgis-3 should not be a synonym of pyqgis because with QGIS 3, pyqgis uses python3 and Qt5 (as compared to Python2 and Qt4).
The difference is significant, and there are many breaking API changes so that answers to the two tags may not be compatible. If only one tag is used, there will be confusion.
In a similar situation for openlayers,...
I would opt for sticking with python-3 because, as @MrXsquared has commented, there is a space between "Python" and "3" at the Python 3.0 Release home page.
It looks like the usage within the few questions it does have are about differences between different versions of a software/application or where to find specific versions of software.
In the first case, the software/application tag is probably sufficient and some of those tags have version specific tags as well that should be used
For example, "How ...
It is not clear in MapInfoNewbie's answer what to do with the qgis tag, hence, I assume the suggestion there (in response to what was asked in question) is just to eliminate/synonymize minor version tags such as qgis-2.8 and qgis-3.2 in favour of respectively major version tags qgis-2 and qgis-3.
I believe we should keep qgis and use version tags only when ...
If we are looking at some Oracle tags then I think it may be worth looking at them in context with all our Oracle tags.
If you use [*oracle*] in the search bar it expands to [oracle] or [oracle-spatial] or [oracle-11g] or [oracle-10g] or [oracle-12c] or [cx-oracle] or [oracle-map-builder]
In total there are 627 questions with an Oracle tag on them. The ...
This is another situation that supports the original version tag guidelines as used on other exchanges - don't use one unless the question or issue is specifically related to the version. That said, this question doesn't appear to be considering initial tagging, but rather editing, modification, and merging after the fact. In such a case, and with the horses ...
As each dot release of ArcGIS Pro has occurred I have wondered whether or not version tags for it might be desirable.
I have been a proponent of version tags for dot releases of the ArcGIS platform (ArcGIS for Desktop, ArcGIS for Server, ArcGIS Engine, etc) but have so far refrained from creating them for ArcGIS Pro. I think there is a difference between ...
My preference would be to standardize on StackOverflow's Python tag names (python, python-2.x, python-3.x, python-2.6, python-2.7, python-3.4, etc) as well as their tagging recommendations according to the Python tag wiki @ChrisW mentioned:
Use the python tag for all Python related questions. If you believe your question includes issues specific to ...
I do not agree. There are significant changes to ArcGIS in v10 later versions, including but not limited to:
Support for ASPRS LAS v1.4.
Support for GDA2020.
Classify LAS building and Tile LAS tools.
Read more about What's new in 10.5. The sub-releases only contain minor changes and bugfixes but each minor release contains significant changes. If a user is ...
I think we should make:
all the ArcGIS 10.x tags become synonyms of an arcgis-10 tag; and
all the ArcGIS 9.x tags become synonyms of an arcgis-9 tag
The reasons that I think we should do this are:
to simplify ArcGIS version tagging
the case for separate dot release tags was strong in the ArcGIS 9.1, 9.2, 9.3, 10.0 and 10.1 era but with each ...
I agree with @PolyGeo's original and now deleted answer to this but just wanted to add a couple of points:
For many users it's difficult to actually know whether a question or problem is exclusive to a particular version but they usually know the version that they are using.
Since it's better to err on the safe side and include rather than
You've mentioned it already, but the first thing that popped into my mind when I read this was QGIS. The problem here is that version numbers mean different things depending on the software. You can't really say Arc 9.x, and depending on what you're asking about you can't say 10.x either. I don't know enough about how QGIS works - if it's similar or if you ...
At the time this question was asked, nearly 6 years ago, I was an advocate for version tags. However, since that time I have come to view them as having little value.
I think that as long as any version(s) being asked about, and hopefully tested and reported on, is/are mentioned in the body of a question, then I think it/they are best left out of the tags.
I fully agree with the arguments you make in the question, which I consider an answer in itself.
Version tags should only be used when answers to a question will only be useful to that specific version. Matt Wilkie makes a nice summary in his comment on Formatting tags relating to version numbers?
People should be encouraged to use version tags only if ...
I'd agree that pyqgis-3 should be a synonym of pyqgis, and you should suggest it (I don't have enough pyqgis rep to do so myself). but we'll need a mod to create it since SE thinks it's a version specific tag.
After that, it could be merged like the other synonyms we have, although possibly at a later date.
In support of MapInfoNewbie's answer I would favor to completely remove either all supplement tags (qgis.x & qgis-x.x) or the version-less tag qgis, but then I'd like the idea of maintaining major version tags qgis-3 & qgis-2 better, with the reason being that those versions do have significant differences in most aspects of the software.
I also do ...
At one time I was an advocate for version tags but over the years my view on them has changed to being that they are of limited use.
Nowadays, as long as the version(s) being asked about (and presumably used) is/are mentioned in the body of the question, then I think they are best not tagged.
Likewise, if answers cover a range of versions and are suspected ...
Here at GIS SE, I think our python-* requirements are, and are likely to remain, more modest than at Stack Overflow.
Once we know that a Python spatial library is being used, then the key remaining thing to know is whether Python 3.x or Python 2.x is involved, because the former is not backwardly compatible to the latter.
Despite python-2.7 and pytho-2.6 ...