The purpose of MATSim yearly releases?

[michalmac]

I am just wondering if we need the yearly releases. They require a lot of effort (maintaining branches for fixing the old versions, both in matsim-libs and matsim-code-examples). Fixing a bug in multiple versions at the same time (e.g. by pushing one commit to several branches) is very hard and rather unrealistic for older versions.

Maybe having weekly and PR-based releases is all we need? In rare cases when we need to fix a specific release, we can create a dedicated branch that stems from the commit for which that release was created.

I do not know all possible ways MATSim is used, so I may overlook the point of having the yearly releases.

[jfbischoff]

Mhm, I think many users associate the yearly version with "a stable release", which is not necessarily true. So, the main purpose of those releases is probably marketing-related.

One could probably replace the yearly releases by something auto-generated, i.e., a three-monthly MATSim release with a proper number attached (I imagine something coded Matsim 2023-w23 is not necessarily appealing to a new beginner). That short cycle would, in my opinion, make any service promises in terms of bug fixes redundant.

[EwoutH]

What could be done is a simple, date based, monthly release cadence. So you get YYYY.MM versions, like 2024.1 to 2024.12. If a bugfix is needed, that becomes 2024.1.1. Only the most recent monthly version is supported, so bugfixes only has to be backported to one release (the latest monthly). That branch will never be more than a month out.

It could even include a built-in pre-release period. For example, on the 1st of the month a release branch is split off and a release candidate (as a pre-release) is created (for example 2024.1.0-rc0). Then, a week later on the the 8th the stable release is tagged (2024.1.0). Then, any backport triggers a new release (making 2024.1.1 etc).

I think this could be (almost) fully automated.

Bit of background: https://calver.org/

[kainagel]

An important aspect of annual releases is that we can tell people "you are using a really old version, and we really do not want to support that any more".

This would presumably work better with release numbers based on the year. If we do not forget, my plan would be to do that for the next release. (*)

Apart from that, we have weekly releases. If adding monthly releases helps, then we clearly could do that. Clearly, we could number weekly releases as <year>.<week> rather than <version>.<week>.

[EwoutH]

On thing that would be useful to me is having a more frequent standalone / GUI release.

[Janekdererste]

On thing that would be useful to me is having a more frequent standalone / GUI release.

Unfortunately, I don't understand what you mean by that. Could you elaborate please?

[EwoutH]

There isn’t an development version of the GUI build on https://matsim.org/downloads/#gui

[Janekdererste]

Apart from that, we have weekly releases.

Do we still have weekly releases? I thought we got rid of them in favor of yearly releases in combination with PR-releases.

I think it is good to have a yearly release because it is easy to understand for newcomers. Also, this version doesn't change frequently, which releases users of the burden of updating their MATSim version all the time (At least I would feel that pressure).

Everyone else, has to learn the second concept of pr-releases then, which works - at least for our group - very well I think.

[mrieser]

Do we still have weekly releases? I thought we got rid of them in favor of yearly releases in combination with PR-releases.

Looks like they are still being built:

https://repo.matsim.org/#browse/browse:matsim:org%2Fmatsim%2Fmatsim%2F16.0-2024w09

[Janekdererste]

There isn’t an development version of the GUI build on https://matsim.org/downloads/#gui

I see. I will ask the same question as in #3124: Is there anything in particular you are interested in?

Furthermore, I think users need to run a "development version" i.e. a version of matsim-libs which works differently than the one from the last release only if they have implemented something in matsim-libs. If a user can do that, they are probably also capable of updating the dependency of the matsim-example-project to the pr-release with which their feature/fix was merged.

[Janekdererste]

Looks like they are still being built:

Storage is cheap, I guess :-)

[michalmac]

We have 3 deployment workflows: https://github.com/matsim-org/matsim-libs/tree/master/.github/workflows

• on PR merge
• weekly
• on release -- used for yearly (pre-)releases

We stopped deploying snapshots some time ago.

[kt86]

The weekly once are I think even more intuitive as the PR-based once. And they are in a chronological order: i) you get one for each single week, and ii) w05 follows w04, etc..
Both is not given with PRs-based releases.
So I am very happy to have both PR and weekly releases. :)

[Janekdererste]

And they are in a chronological order:

The pr-releases are numbered in ascending order. If we have the space, we can keep the weeklys of course.

I just don't want to get rid of the yearly release! :-)

[mrieser]

To come back to the original topic:

The main difference (I think) is:

• The official yearly release is a zip-file that contains the matsim-jar that can be started by double-clicking to run the GUI.
• The PR/Weekly releases are "only" Maven artifacts, so there is no complete zip-file to download and run the GUI.

And I think that's to some point deliberately, as the message on the website states. The zip-file is mostly to get started and test MATSim. If someone is serious about using MATSim, especially with the latest feature, they should not rely on prepackaged zip-files, but work in an IDE with the latest dependencies.

Which then results in the question: How often do we want to provide a zip-file release? once a year? twice a year? Every quarter? And could we automate the creation of these zip-releases as well?