Activity

1. hut

   added this to the v2.0.0 milestone on Aug 7, 2026
2. hut

   added

   needs-opinions

   on Aug 7, 2026
3. hut commented on Aug 7, 2026

   

   hut

   on Aug 7, 2026

   MemberAuthor

   More actions

   Another thing that's worth specifying is how to call development versions. I think it's unacceptable that the most up-to-date version on the master branch (as of writing) is ranger-master v1.9.3-979-gd45f14c0 (see output of ranger --version) while the 2-year-old bugfix release is ranger 1.9.4.

   As you see, the newer version with more features and more bugfixes has a lower version number than the older one. I find this confusing and IMO this should never happen.

   Instead, I would always set the version number of the master branch to the highest version that has been released.

   In another project, I add a "-dev" suffix for non-release versions. We could benefit from this too. Currently we use git describe to generate the v1.9.3-979-gd45f14c0 but if git is not installed, it falls back to v1.9.3 which is confusing in multiple ways IMO:

   1. ranger's version is reported differently depending on whether git is installed?!
   2. multiple ranger versions can report v1.9.3 as a version?! there should only be one.
      • Yes, the non-release versions would say ranger-master v1.9.3 instead of ranger v1.9.3, but IMO the differentiation should be unambiguously visible in the version number, not the word that happens to be standing before it.

   For reference:

   ranger/ranger/__init__.py

   Lines 17 to 44 in d45f14c

   	# Version helper
   	def version_helper():
   	if __release__:
   	version_string = 'ranger {0}'.format(__version__)
   	else:
   	import subprocess
   	version_string = 'ranger-master {0}'
   	try:
   	with subprocess.Popen(
   	["git", "describe"],
   	universal_newlines=True,
   	cwd=RANGERDIR,
   	stdout=subprocess.PIPE,
   	stderr=subprocess.PIPE,
   	) as git_describe:
   	(git_description, _) = git_describe.communicate()
   	version_string = version_string.format(git_description.strip('\n'))
   	except (OSError, subprocess.CalledProcessError, AttributeError):
   	version_string = version_string.format(__version__)
   	return version_string
   	# Information
   	__license__ = 'GPL3'
   	__version__ = '1.9.4'
   	__release__ = False
   	__author__ = __maintainer__ = 'Roman Zimbelmann'
   	__email__ = 'hut@hut.pm'

   TL;DR:

   1. When a version is released with a higher version number than the master branch, update the version number in the master branch to that
   2. Add a suffix like "-dev" or "-beta" to the version number of the master branch
   3. Remove the soft git dependency in version reporting of master branch versions
4. FichteFoll commented on Aug 7, 2026

   

   FichteFoll

   on Aug 7, 2026

   Last edited by FichteFoll

   Contributor

   More actions

   Having participated in various discussions on the semver repository, I just want to mention that strictly following SemVer for software with a user interface is almost never going to be a perfect fit and you will have to make some compromises as to what defines a breaking change. For example, some people might consider the removal or replacement of a certain configuration option breaking because it requires manual migration effort. The way I see it, SemVer is best suited for libraries with a strongly define public interface like an API, but that does not mean it is impossible to use for other software – you'll just have to wing it sometimes.

   (The other thing you need to consider is to plan breaking changes well ahead of time and group them together to reduce the number of migrations end users have to make in favor of doing larger changes in one big release while at the same time not holding back changes for too long. This is always a tough decision but I believe it will be worthwhile. And it's identical with any other software that uses SemVer, so it's no different for tools with user interfaces.)

   When a version is released with a higher version number than the master branch, update the version number in the master branch to that

   Strong +1 to this. This also got me and my package manager confused.

   Add a suffix like "-dev" or "-beta" to the version number of the master branch

   Since ranger is written in Python, you may want to consider following PEP-440.
   In some internal tooling, I made CI builds output a version like 1.2.3.post1.dev<pipeline-id> for versions that were built on the base of a previously released 1.2.3. That way I would not need to decide on a whim whether the next version will be 1.3.0 or 1.2.4 (or 2.0.0). However, going with 1.3.0.dev<some-incremental-number> as a default is also fine if you are considering using a dedicated hotfix release branch to backport fixes for 1.2.x.

   Remove the soft git dependency in version reporting of master branch versions

   I personally do not want to deal with dynamic version generation outside of a VCS, so I cannot give any input to this other than "I wouldn't".