RFC: date-based version numbering?

[ralfbrown]

Given that the Christmas release will (barring a big surprise) be an incremental evolution rather than a fundamental rewrite/break and that lots of software uses date-based version numbers (e.g. Hugin 2023.0), would it make sense to switch darktable's version numbering to reflect the year? E.g. the Christmas release would be 25.0, next summer's 25.2, and next Christmas 26.0. Dev versions would be 25.1 and 25.9.

[jenshannoschwalm]

I agree on this proposal. Would also make clear the release time on first sight.

[wpferguson]

I think it would cause lots of confusion for a release or two, then everyone would get used to it.

[TurboGit]

I had thought about this, I'm quite neutral on this but why not. As we are at it, why not use the month?

Next release will be 24.12 and the bugfix on Feb would be 25.02 for the dev release we could add the letter d. That is after 24.12 we would have 24.12d.

So the darktable releases would be:

• 24.12 (winter release)
• 25.06d (dev interim release, will become the 25.06)
• 25.02
• 25.06 (summer release)
• 25.07
• 25.12d (dev interim release, will become the 25.12)

But for the bugfix release we have sometime two the same month (4.4.1 & 4.4.2). Do we need a bugfix number:

• 25.06.0 (summer release)
• 25.07.1 (bugfix)
• 25.07.2 (bugfix)
• 25.12.0d (dev interim release, will become 25.12.0)
• 25.12.0 (winter release)

So at the end, not that simple.

[ralfbrown]

As you note, adding the month adds complications. Hugin only uses the year, the minor/patchlevel versions have no relation to time of year.

[da-phil]

I had thought about this, I'm quite neutral on this but why not. As we are at it, why not use the month?

Next release will be 24.12 and the bugfix on Feb would be 25.02 for the dev release we could add the letter d. That is after 24.12 we would have 24.12d.

So the darktable releases would be:

* 24.12 (winter release)

* 25.06d (dev interim release, will become the 25.06)

* 25.02

* 25.06 (summer release)

* 25.07

* 25.12d (dev interim release, will become the 25.12)

But for the bugfix release we have sometime two the same month (4.4.1 & 4.4.2). Do we need a bugfix number:

* 25.06.0 (summer release)

* 25.07.1 (bugfix)

* 25.07.2 (bugfix)

* 25.12.0d (dev interim release, will become 25.12.0)

* 25.12.0 (winter release)

So at the end, not that simple.

The latter would even look like semantic versioning, which might be confusing indeed.

I like the hugin way of versioning as well, is pretty simple & straight-forward and flexible in terms of interim / patch releases.

[rgr59]

If a decision is made for the new versioning scheme, I think a 4 digit main version like Hugin (2024.12, ...) would be better, so it is immediately obvious this is a year.

[ralfbrown]

LibreOffice has just switched to year-based versions as well - when I ran software update on my PC last night, it jumped from 7.6.x.y to 24.2.x.y, and I see that there's a 24.8.

[wpferguson]

The problem I see is bugfix releases.

• 24.12 - Winter release
• 25.02 - butfix release to 24.12?

I think bugfix releases should be the original release with a point version. In the above case the bugfix should be 24.12.1. Otherwise users will start thinking there are 4+ releases per year.

[ptilopteri]

• wpferguson @.***> [10-05-24 14:12]:

The problem I see is bugfix releases.

• 24.12 - Winter release
• 25.02 - butfix release to 24.12?

I think bugfix releases should be the original release with a point version. In the above case the bugfix should be 24.12.1. Otherwise users will start thinking there are 4+ releases per year.

perhaps make the point fix a letter rather than a digit?

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

[TurboGit]

Ok so what about dev release ends with 0 first release ends with 1, corrective release with 2, 3...

It would give us:

• 24.12.1 (winter release)
• 25.06.0 (dev release, will become summer release)
• 25.06.1 (summer release)
• 25.12.0 (dev release will become winter release)
• 25.12.1 (winter release)

?

[victoryforce]

Ok so what about dev release ends with 0 first release ends with 1, corrective release with 2, 3...

It would give us:

• 24.12.1 (winter release)
• 25.06.0 (dev release, will become summer release)

So minor is the month number of the planned release and corrective releases will increment patch number. If after the December planned release we decide to make a corrective one, say for example in January, should it be 25.01.02? And if we have to release another one in March, should it be 25.03.03?

I find it a bit confusing.

Also, everyone will have to relearn and get used to the fact that the development version will be tagged differently. By the way, not only enthusiastic users, but also package maintainers in distributions.

My suggestion is as follows. Major indicates the year of release. But we do not display the release month number in the version. Instead, minor "0" indicates the first planned release of the year, and "2" - the second. That is, if the planned release is 25.0.0, then if we issue corrective releases to it, we increase the patch number, it will be 25.0.1, 25.0.2, ... (the same as now). Development snapshot tags will be odd, as they are now: 25.1.0, 25.3.0.

The benefit of this numbering scheme is that the already familiar pattern (even minor - release, odd - development) does not change. Only the major version number (the change of which has no logical explanation other than "the time has come") is replaced by the year.

[elstoc]

Yes I think I agree regarding use of the month number in the version name being confusing. I would probably prefer to have some other way to mark development releases than using an odd number, so that we could just have 25.0.0 is the first major release of 2025 and then 25.0.1 is a patch to it, 25.1.0 is the second release etc... or even 25.1.0 is the first major release and 25.2.0 is the second.

Certainly I dislike "arbitrarily" going from 4.8.0 to 5.0.0 (it feels like 5.0.0 should be "more major"), but also dislike (even more) going from 4.8.0 to 4.10.0 (which means there'll never be a 5.0.0).

Year-based is fine, but it does still become problematic when we do a feature release in one year and a fix release the next.

We could also consider a naming convention that does away with the first point, thus removing any unintended "meaning" from the "X.0.0" release. So 4.8 would be followed by 50.0 (fix release being 50.1), then feature releases 52.0, 54.0, etc.

[victoryforce]

Yes I think I agree regarding use of the month number in the version name being confusing. I would probably prefer to have some other way to mark development releases than using an odd number, so that we could just have 25.0.0 is the first major release of 2025 and then 25.0.1 is a patch to it, 25.1.0 is the second release etc... or even 25.1.0 is the first major release and 25.2.0 is the second.

The latter is how GCC numbers its versions since like GCC 5 (ie, the first release version of major <X> is <X>.1).

I would probably prefer to have some other way to mark development releases than using an odd number

The key question is how? Not that this is such a fundamental issue, because after all, ordinary users do not deal with dev-versions and do not need to know how to distinguish them. But, we just need to mark with some tag the starting point of the development of the next version in master. OK, using odd numbers is not the only solution, we can tag with the next release number with "-pre" suffix. For example, 25.1.0 could be a release, and development snapshots would have versions like 25.2.0-pre-<commitcount>-<githash>.

Certainly I dislike "arbitrarily" going from 4.8.0 to 5.0.0 (it feels like 5.0.0 should be "more major"), but also dislike (even more) going from 4.8.0 to 4.10.0 (which means there'll never be a 5.0.0).

Well, going from 4.8.0 to 4.10.0 doesn't mean there will never be a 5.0.0. It just means that, assuming our X.Y.Z versioning is semantic versioning (which is quite expected for three-number versions), 4.10.0 does not contain any changes that would justify increment of a major version.

Our main problem is that we have not formulated exactly what changes in the program will justify the increment of the major, and the change of the major is arbitrary.

Year-based is fine, but it does still become problematic when we do a feature release in one year and a fix release the next.

This will not be a problem if we declare that a release at the very end of a year is the first release of the next. I don't see a big stretch in releasing 25.0 on December 21, 2024. In fact, I think this is the most logical way. It would be better if in the first half of the year the release with the number of this year, not the previous one, was relevant.

So 4.8 would be followed by 50.0 (fix release being 50.1), then feature releases 52.0, 54.0, etc.

This reminds me of the nonsense used by Chrome and Firefox in an effort to give the user the impression that development is faster than that of a competitor. :)

[elstoc]

Our main problem is that we have not formulated exactly what changes in the program will justify the increment of the major, and the change of the major is arbitrary

Yes this is what I meant. If we went to "major version" only changing for "major changes" then unless we do something like upgrading to Gtk4 I doubt we'll ever find an argument to justify incrementing the "major" version number again.

[ralfbrown]

I don't see a big stretch in releasing 25.0 on December 21, 2024.

Less of a stretch than automobile model years - the 2025s have already been on sale for months....

The latter is how GCC numbers its versions since like GCC 5 (ie, the first release version of major <X> is <X>.1).

And GCC has been using one major version per year since that change, so GCC 13 in 2023 and GCC 14 in 2024.

[TurboGit]

Actually I do update the major version when the minor is at 8. So 4.8 will be succeeded by 5.0, there is no semantic with the current choice. I'm not saying that it is good, just saying that it is the way it is to avoid the confusing 4.10 greater than 4.8.

[elstoc]

I do update the major version when the minor is at 8

Yeah that's my point -- it's not an indication of anything that is actually a major change but just that 5.0 looks less bad than 4.10. But people do read 4.8->5.0 as more significant than 4.6->4.8 whether they should or not.

So the main option to avoid that choice (between two bad things) is to change the naming convention.

[victoryforce]

Our main problem is that we have not formulated exactly what changes in the program will justify the increment of the major, and the change of the major is arbitrary

Yes this is what I meant. If we went to "major version" only changing for "major changes" then unless we do something like upgrading to Gtk4 I doubt we'll ever find an argument to justify incrementing the "major" version number again.

We could define more or less clearly what exactly we would consider "major changes". Strictly speaking, semantic versioning defines "incompatible API changes" as the reason for the increment of major. darktable doesn't have a public API, so for versioning that resembles semantic versioning, we'd have to state what changes in the program cause the major to be incremented.

It could be, indeed, a major redesign of the program for a new version of the toolkit UI. It could also be, for example, adding new modules. It could even be a change in the version of the library's database schema (although we still change the schema so often that almost every new release will have a new major).

However, if we don't want to bump the minor version up to 10 so we don't have a problem with people sorting the version numbers alphabetically instead of numerically, then none of that matters and we're really better off going with year-based versioning.

[elstoc]

if we don't want to bump the minor version up to 10

I think we kinda decided this when we last had this discussion (when moving from 3.8 to 4.0). For me it was just a dislike of things that look like decimals but aren't (plus the fact I thought we'd stay on 3.X forever)

[victoryforce]

In Debain, they are already going to make an experimental darktable 5.0.0-rc0 package. I think it's time to make up our minds and make a decision whether we stay (at least for one more year) on the old versioning system or adopt the new one.

[TurboGit]

At this stage there is no consensus and it is way too late to change the versioning.

We need to restart the discussion very early on 2025.

[elstoc]

I think the point being made here is that if we went with the proposal, our first release under the new naming convention would be either this Christmas (the 2025 release) or next Christmas (the 2026 release), so no need to properly decide until June next year if we're not going to change the next release.

[TurboGit]

I don't think that's true, we may have a dev snapshot on 5.1 and still release in June could be 25.0.0 and the corrective release in July 25.0.1... And in December 25.2.0 (if we follow @victoryforce proposal).

But the discussion is so convoluted that I'm not even sure we are are in line about this, hence the fact that I don't think we are ready for the next release.

Also note that I need some time to review/update the scripts to build the release to ensure they work ok with the new scheme.

[elstoc]

I don't think that's true, we may have a dev snapshot on 5.1 and still release in June could be 25.0.0

Yeah, I had assumed we would want the dev release to follow the same convention and start with the first release of 2025 but you're right, that's not necessary

But the discussion is so convoluted that I'm not even sure we are are in line about this, hence the fact that I don't think we are ready for the next release.

Agreed. At the end of the day, you're the maintainer and you're still doing all of the work relating to releases, so it's your call. There will always be people who disagree with whatever call you make.

[gordhub]

This will not be a problem if we declare that a release at the very end of a year is the first release of the next. I don't see a big stretch in releasing 25.0 on December 21, 2024. In fact, I think this is the most logical way. It would be better if in the first half of the year the release with the number of this year, not the previous one, was relevant.

One way to eliminate any confusion in this area would be to switch the winter release from Christmas to New Year's Day. I know this might be perceived as kicking a cherished tradition to the curb. However, having a release right before year end seems to be causing unnecessary mental gymnastics.

Personally, I think it would be good to use the 4-digit year as the first qualifier to make it obvious that it is a year rather than a number with some other meaning;

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[ralfbrown]

Let's continue any discussion in #18159.