Are the minor releases actually worth it?

The problem is that these topics are related. The current situation is a trade-off between wishes of various groups and what can be achieved with the available manpower.

So, if the consensus is that the minor versions (the steps towards a new LTS) cannot have breaking changes and can’t remove deprecated code then the available manpower isn’t capable to continue with the current release cycle. Development will slow down or there won’t be LTS versions or …

There is another topic about EEELTS versions. Sure we can support every release for 20 years. But with the available manpower that means we have to drop something else. Development will slow down or major versions will be released only every 10 years.

Another use for the minor releases is that there is a feature freeze for every minor release which provides some time to test everything. In the past we were busy making feature for a long period and then had a longer feature freeze period with alpha and beta releases. The sad truth was that hardly anyone (thank you very much to those who were the exceptions!) tested these. Most bugreports came after the release and especially after the x.y.1 version because many people waited for the first bugfix release as they expected that the x.y.0 version wasn’t really stable and the most annoying bugs would be fixed by then.

To end with a lighter note; I really liked how Mathias’ answered when an agency requested a large feature after a presentation: Cool, we’ll do that, just send over a team of developers.

1 Like

I think the minor versions are just named a bit odd, because it seems to me that they are rather release candidates than actual versions of the system. So for TYPO3 8 this would mean for me
8.0 -> 8RC1
8.1 -> 8RC2
8.2 -> 8RC3

8.6 -> 8RC7
8.7 -> 8LTS

Something like this would make it a little bit more clear what the minor versions really are. One could argue with those release candidates a bit better, because it is also used for other software such as android roms or our own projects, where we show our customer release candidates that still are under development and may receive a few changes down the road to the actual release date.

Minor versions change to much to be called release candidates. From the amount and type of changes, they can be called alphas (like someone already mentioned above), but they are too stable to be called an alpha.

Maybe we should make it more clear what promises and what burdens come with minor releases in contrast to LTS releases instead of trying to match our way of development to models that to not fit reality.

2 Likes

Yet they are too unstable and breaking to be released as a minor version (according to semantic versioning). I tend to repeat myself but it would help a lot to not have these breaking changes in minor versions. Not only for the people I mentioned over and over in this topic, also for the ones from the outside that are not familiar with TYPO3 and expect the project to follow semantic versioning.

Yes, would be quite helpful but still does not answer the question if these minor versions are actually worth it then given their adoption rate. What is the benefit of these releases while facing all the drawbacks? I don’t even get how the amount of minor versions is defined.

Next Major Version - 1?

Does it mean, the development frame for each minor version decreases or will it remain and the next LTS release will be shift further into the future? How does that perform in the future?

Semantic versioning works only for libraries and small projects. Bigger projects simply cannot keep the strict scheme up, because they whenever they need to make bigger changes, a certain instability cannot be avoided. Either you adopt a major versions only release scheme (like firefox or chrome) or you block yourself due to the formalities until most contributors give up.

Never forget that TYPO3 is an open source product that is driven by volunteer developers. You need to keep their motivation up in order to keep the contributions coming. Keeping the motivation to contribute high, is one of the key factors for keeping an open source project alive.

We do not have the manpower to incubate bigger changes in a way that they can be merged at the beginning of the development of an LTS version. Because of this, we need to develop and merge changes as they come in. For bigger changes, that means that some minor versions might be a bit more unstable than others. We do try to develop TYPO3 as stable as possible, but certain changes cannot be avoided if we want to keep the pace up. And we need to keep the pace up, otherwise maintenance becomes harder and we cannot adopt new technologies or use synergy with other open source projects, because our code base is too ugly and technical problematic to be combined with modern concepts.

As Jigal already explained very well, the current concept was derived from many discussions and after trying different concepts and is a compromise of the needs of all involved parties.

Each minor version is centered around a certain topic that should get tackled during its development time. The numbers depend a bit on the schedule that is defined by the predefined release dates and the events around it. So we will properly have between 6-8 minor versions. The last minor version then becomes the new LTS version.

The major version -1 is coincidental in the last two releases: 4.5, 6.2, 7.6, 8.7

1 Like

From an outsider’s perspective this doesn’t look good:

  • We produce a lot of breaking changes, but
  • We include breaking changes in minor releases, because
  • If we used semantic versioning we would have many major versions, because
  • We produce a lot of breaking changes (repeat)

It looks like circular reasoning attempting to justify why we don’t do what other projects do. And I think that’s one of the points Alex makes.

Digging down to the core of the issue we find that TYPO3 being a monolithic application is a big part of the issue. Because of this, any breaking change to any minor component in this monolith logically produces a new major release.

If we begin the work of decoupling system extensions (I’ve researched this already; the total number can be reduced to ONE system extension plus N decoupled optional extensions) we wouldn’t have this problem and we would finally be free from the concern that any breaking change anywhere is a breaking change to the whole.

ExtDev: "Cool a new version of TYPO3. Let’s see… oh, it’s a minor version so no breaking changes. I’ll quickly update the compatibility of my extension and I’m done"
Customer: "Your extension produces a fatal error with the new TYPO3 version"
ExtDev: "Huh, it’s just a minor release. Hmmm… found a change in one of the system extensions. Fixed!"
ExtDev: "Found more changes in system extensions. Hey, they have a new major version!?!?"
ExtDev: "Core team, the new minor TYPO3 release has several breaking changes in system extensions. How can that be a minor version??"
CoreTeam: “Those are changes in the decoupled system extensions; the core itself doesn’t have breaking changes.”

Remember that not everybody builds their TYPO3 installations with composer. We still have to offer a complete package with all the functionality of the system extensions in it.
Also, if there are changes in upstream libraries that result in breaking changes in our API or in functionality then the resulting product TYPO3 CMS has a breaking change.

Recommended best practice for declaring constraints is to include the names and versions of system extensions which are required by any extension. You declare dependency on the individual extensions (= typo3/cms-core + typo3/cms-workspaces) rather than the distribution (= typo3/cms).

You’re making this a lot more difficult than it has to be, Jigal.

We do not have minor versions! We have snapshots and LTS versions.

If this is not clear, then we better document this better. Maybe even change the version/naming scheme instead of trying to press ourselfs into an artificial process that simply does not work out for us.

You completely ignore the part about volunteers and motivation. The current process balances contributors and agencies requirements while keeping the maintenance burden for the core devs lows. Any proposed solution needs to be better than that.

This is dangerously close to being just another step in the circular logic I sketched above…

I’m very well aware we don’t do what other projects do. That’s what I tried to get across that maybe we should reconsider. And I then present a longer-term vision for how this might come to pass completely naturally without increasing the load on core developers - in fact lowering it significantly; assuming that some core exts can be turned into community extensions - and allowing each to evolve without being under constraints from the core of TYPO3.

Not at all, I like motivated volunteers. That’s why I sit here, past midnight on a Sunday night, getting all my arguments shot down before they even take of while trying to motivate current volunteers to see a different path. It ain’t easy let me tell you.

This topic was automatically closed after 28 days. New replies are no longer allowed.