Are the minor releases actually worth it?

This topic is inspired by the answer of Helmut Hummel in the minimum requirements topic (https://decisions.typo3.org/t/minimum-requirements-for-typo3-v9/149/18)
and the topic auf the LLTS (https://decisions.typo3.org/t/agency-oriented-typo3-lifecycle-aka-llts/169/9).

I’ll start with a quote:

  • TYPO3 develops way too fast, our devs can’t hold pace.
  • TYPO3 should be more stable… I want 10 years of support for a version (sic!)
  • TYPO3 does not invent fast enough, modern techniques are not adopted fast enough

At first all these statements sound contradicting. But I think part of these problem is the current release policy.

TYPO3 develops way too fast, our devs can’t hold pace.

I disagree, that the development is too fast but I totally agree that the pace is too high. Especially for those that cannot adopt new versions in time for whatever reasons. This does apply mostly for the minor versions. The adoption rate for minor versions like 7.0-7.5 is very low due to several problems, one of them being a too high pace.

TYPO3 should be more stable… I want 10 years of support for a version (sic!)

Yes, everybody wants this. And TYPO3 is pretty stable at all. I think whenever people refer to stability, they first of all think of breaking changes. While these changes are necessary, you can mostly struck by them during minor version upgrades. During the last 4 years I work as a freelancer, I was never ever asked to perform a minor version update. Neither was that requested by the client itself, nor could it be sold. Dealing with breaking changes every two years is simply less expensive than doing it every 3 months.

TYPO3 does not invent fast enough, modern techniques are not adopted fast enough

To be honest, I never heard this from a customer. This is developers speaking. And it’s not a problem at all. I am a developer myself and like to embrace all the good changes that make my life easier. However, there have been very few changes in the past that made such an impact so that a client could have had a desire to upgrade. One example of such a thing would be Doctrine DBAL for a client with a desire to switch from MySQL to MSSQL. Let’s face the ugly truth, the clients do not recognize the Form-Engine rewrite in the first place. Neither do they realize the switch from Ext-JS to jQuery.

I don’t know how many core developers and contributors have to actually sell their software but I do more and more think that it would be good to do that as a role play game for every released version. Ask yourself, why your customer should do the switch from 7.3 to 7.4. How much is the benefit compared to the impact of breaking changes? Is it possible to sell 4 small features in time when there is a need to adjust dozens of hooks.

It’s as simple as that. There need to be enough improvements to justify the amount of time given and money spent to do the minor version upgrades instead of just using the LTS versions.

What if we treated TYPO3 as a product?

This question sounds strange. It implies that we do not treat TYPO3 as a product and that’s what I mean. Seriously.

Let’s have a look at why there is a demand for software updates anyway. Mostly it’s clients having feature requests. It’s really simple. You get a call from your client and 99% it’s about “can we have this or that, it would make our lives easier”.

I wonder why we don’t have a look at that in the first place and see which nice features can make it into the next version.

I know, it’s open source and part of that is, that people work on whatever they like. Still, I am sure that there are enough feature requests that are lovely enough to find someone to work on.

So, instead of releasing software by date, why not release software by milestone and set a soft deadline? This would be much easier to sell and it would raise the joy about each new version a lot.

One could finally sell features long before an LTS version is released.

  • Next version contains the frontend editing, for sure.
  • The version after we have native routing, really!

Currently this is not given, making people struggle to sell new TYPO3 versions beyond the aspect of security.

Does semantic versioning help?

I am sure about that.

See the statement of Helmut Hummel about that. It really lowers the burden for everyone to not have breaking changes in minor versions.

For the ones that sell the software and for all the extension developers that can focus on the next major version instead of making something compatible for a specific minor version.

Résumé

Please let’s reevaluate the current release cycle that is much more date than feature driven and make every release worth it again.

1 Like

My opinions stated as succinctly as possible:

  • Adopt semantic versioning and designate a support scheme that is the same for any major version.
  • Start releasing public betas again; encourage users to do test-upgrades with these to discover any issues.
  • Do not schedule promised releases for major versions many years in advance.
  • Schedule releases (majors and minors) when there is enough to merit one.
  • Warn in ample time ahead of releasing a new major version.
  • Optionally, designate a backporting strategy for both bugfixes and features (consider automating it if the tests are deemed sufficient).

I agree with OP for the most part but will add:

Let’s face the ugly truth, the clients do not recognize the Form-Engine rewrite in the first place. Neither do they realize the switch from Ext-JS to jQuery.

That may not be the case, but they recognise the concept of browser support and not requiring discontinued libraries - although we could be better at explaining why library XYZ is a priority.

1 Like

Maybe it’s worth looking at gitlab release strategy. They have a really high upgrade rate … and the always release something new on the 22nd may it be an update or an upgrade …

TL;DR: Changing the release cycle again, and again, and again is something we should not consider at all.

The whole concept of fixed release cycles with scheduled dates, service level agreements, partner programs with extension and project reviews and certification of developers, integrators, consultants and editors has been setup to generate the most important thing for any product: Trust!

If we start releasing versions just as we like because it took us too long to finish a certain feature to get the “merits” to be a new release, we will lose this trust after a very short time, because none of the agencies and clients will be able to have a long term plan for their project anymore.

So we should stick to the plan, without promising too many things, making releases as scheduled and if a feature is not finished, skipping it and having it done with the next release.

Even Kay’s proposal would be fine then, since it would give us a schedule that can be planned by agencies and clients. But waiting for a collection of features to be done until a new release will be scheduled feels like a step back to a very dark period of TYPO3 development and thus is a No-Go for me.

4 Likes

Sorry Jo, but that’s not what I said. I talked about about a soft deadline and defining features to be shipped until that deadline. It’s not so much different from the current approach but the focus is on the features, not the dates. I’d rather postpone a release for a month but have a great feature to be shipped instead of cancelling a feature because there is a hard deadline.

I believe it’s a myth, that all the agencies out there plan their updates to the very day. It’s ok to know that there is a new version to be released during a specific quarter of a year rather than on a specific day and time.

Actually the part you quoted was meant as an answer to Claus’ reply who mentioned the “merit”. I agree that day and time could be discussed as long as we stick to the scheduled month and the current release cycles. Still feature freeze for a final LTS should not be subject to change.

Alright, let’s rather talk about the release cycle as this is the main topic. I’d like to get some feedback about the questions regarding the minor releases.

  • Do these minor release contain enough features to be sold separately to the clients?
  • Are these minor versions stable enough?
  • Should minor versions contain breaking changes and thus make it very hard, especially for extension developers, to adjust the codebase in time and sell these updates to the clients?

I am working as a freelancer for a couple of years now and had contact with many agencies but I did experience that neither was it possible to sell a minor version upgrade nor that a client requested it. it seems, that the majority upgrades from LTS to LTS to avoid the constant hassle with minor versions.

Is there anyone out there who can speak in favor of these minor versions who successfully sold these version upgrades over the last years, increasing the satisfaction of their clients?

Sorry, I cannot speak for selling minor versions either. I’m using an official LTS for “production” or maybe the HEAD temporarily to get some bug fixes but I don’t upgrade to minor versions anymore (again: on production), except for 1-2 very small websites I’m confident enough with since they basically only use the core and not (many) 3rd-party extensions.

Lately I had a use case where we were very happy to have a fixed date for the release of v8. We should have provided v6.2 to v7 upgrade but due to the calendar and v8 at the corner, and the client fine with paying for ELTS even if only for a few weeks of getting insurance security bugs would get fixed, we moved to v8 right away. The point is we are still not on production since this is a big project, we got problems with infrastructure which took us longer to get and apart from still infrastructure problems, we faced a few nasty bugs in v8 (which must probably partly exist in v7 as well) that just prevent us from going live right now.

I’m very fine with all the latest changes and “cleanup”. Of course I love that. But we still have just too much trouble upgrading from 1 LTS to the next one. Upgrading from 6.2 to 8 will be a very common use case, so we should ensure the upgrade from X to X+2 is as trouble-free as possible, and this is not the case today. Even a switch from X to X+1 is still a bit painful. It’s not just because of the Core itself but because of related 3rd party extensions.

Why are people jumping from X to X+2? Because you cannot do LTS upgrade every 1.5 year and you often start with it at a point where the next LTS is already 1 to 1.5 year old and the over-next LTS is around the corner. Maybe that’s not the case in Germany, but in Switzerland and France (I spoke with them few days ago) that’s just the case. Not even speaking about still in use 4.x-based websites.

I’m a strong advocate of releasing extensions compatible with 2 consecutive LTS versions, just because of the additional security you get while upgrading a bigger website.

Keeping up to date with a small website, more or less only using the core and very very few 3rd-party extensions (like realurl and news and you’re done) is not a big deal, I fully agree! But as soon as you move to “real” websites, then it’s becoming complex.

I like Helmut’s idea regarding semantic versioning and Kay speaking about gitlab is a good example. I’m upgrading every month to the next version and this is just a breeze. Everything is properly documented and the migration steps are either fully automatic or properly documented. I don’t know much about the underlying framework and language but I just read and apply migration steps and… it works!

OK, this would be a usage like using TYPO3 Core solely but still, even like that we deprecate and remove a lot in each version, and I’m sure that prevents developer from upgrading themselves, which in turn prevents them from adapting their extension way ahead of the release, which in turn prevents “normal” agencies from upgrading to the next LTS right when it comes out.

3 Likes

Regarding extension development IMHO the problem is not the core or the pace of the core but the fact that there are too many one-man/woman-shows outthere dealing with extensions in their spare time. When these developers become successful in their business, the spare time they got will decrease, making it hard for them to take care of extensions the way they should do. So even changing the core cycles would not change that situation. But making extension development a part of their business will.

Gridelements is a good example, since we had a much better pace when this extension was part of the Telekom project, which we were paid for on a regular base. Another example is the security hole in news, which was fixed way too late due to the maintainer having to focus on projects he makes a living from.

This is why we are working on the coders.care project, that aims to bundle resources to make extension development a possible business even for freelancers. IMHO this could be a real game changer.

1 Like

Just some more anotation to Xavier’s post:
as it is a fine theory to upgrade from X to X+2: this can’t work without usage of ELTS (or accepting possible security holes).
1st: maybe you can prepare everything for using X+2, but the final upgrade can only be done when X+2 is official released. And then you have to do alle work. Assuming a website with daily changes: you can’t do the update as apreparation two month before release of X+2.
And then you notice that X+2 does not run flawless. every developer knows about software complexity and the problems of bing really bugfree. and so a small site with few features can run stable with a new version, a bigger site with more features will propably find some unnoticed bugs which might prepend the release of the updated site. so yoou need to wait for X+2**.1**
It’s a big difference building up a new website with an alpha release or doing an update for the coming LTS.
you can prepare for the coming LTS with usage of all pre releases, but that costs a lot of time doing tests over and over to verify a working site with each pre release. And that time no customer is willing to pay / no company can afford as ‘study’ time. In the moment the availability of good TYPO3 integrators/developers is very low. I assume they all are bound with updates of all the old installations. And while they do the last updates to 6.2 they now can restart updating to 8 LTS. That gives me as integrator/developer a secure job, but also a very stressful job, as I have to do the work of more than one person as our company can not find enough coworkers.
Maybe the core can continue fast, but it needs more power to the basics to get all the existing installations stable. I fear the moment when TYPO3 is a fine and optimized product but nobody is willing to use it as fewer and fewer people can afford the money (/manpower) to keep up with the evolution of the core.

I get the feeling that adding 1/2 year support to the LTS releases could be enough to get the upgrade path X to X+2 working. As not every extension is ready on a LTS release day.

I like the idea of helping maintainers but I believe that this is not a game changer. Even if I had the time and my work was paid, I couldn’t have dealt with the breaking changes on such a regular basis as I needed to.

Take TemplaVoilà for example. When Wouter and I released a first 7.x version it was compatible up to 7.3 IIRC. Then the form engine change kicked in and since then TemplaVoilà was just broken. The changes were extremely time consuming as one has to learn the changes by reading te code. And to be honest, I am ok to deal with it once for an LTS version but not many times a year.

TemplaVoilà is a special case as it integrates deeply into the core. There are less breaking changes for simple extensions. Still I don’t want to adjust my codebase that much and foster all the different versions. Not even if I get paid for it because this blocks the feature development for future versions. Extension development can’t be to deal with breaking changes 90% of the time and have litte time and money for actual improvements.

If there was semantic versioning I’d have to deal with the same amount of BC but only once. The development pace can still be high but the pressure from the outside goes down. No question if and when there is a compatible gridelements for a minor version any more.

On top of that it’s much easier to sell minor versions because extensions for a major are by default compatible with all following minors. That means that the adoption rate of minors goes up and customers benefit from features much earlier.

1 Like

Actually the idea of Coders.Care is not just to raise funds for single developers but to increase the size of the teams especially when dealing with bug fixes for extensions. Thus giving the actual creators more time (and money) to focus on the actual development of new features.

A breaking change in the core will most likely touch more than just one extension in similar ways, so using the synergy of a team might be even more important than the “built in crowd funding”.

I don’t think the minor versions are that relevant for customers. Heck even I find myself selling LTS over minor updates, because the way I experienced it is, that the LTS versions are much more stable then the minor versions.
Take 8.7, I set up an experimental site on 8.6, but no actual customer project on any version from 8.0 to 8.6 until now, where 8.7LTS is out for quite some time.
For me, it is way easier to maintain a website on a version that is promised to get supported for 3 years, instead of setting it up for a minor version and keep breaking it until reaching the “stable” LTS.
But I may be a bad example, as I am seeing the Ubuntu October releases as Betas for the upcoming April releases of the following year.
The way I see it, the minor updates are interesting for early adopters who are willing to pay extra for painfull updates, or for developers who want to get in touch with the new LTS features ahead of time.

Well, we had the feature focused release strategy before. It did not work out, we lost a lot of trust and market share.

You can think of the minor versions as development snapshots, except that they are stable in themselves and can server as a base for a website. Those snapshots will not receive support after a new snapshot or an LTS is released.

BTW, most problems in modern IT result from companies not updating regularly. The technical dept keeps piling up until it cannot be handled any more. If updates are hard, then you have technical flaws which needs to be addressed. Not updating just hides that. The more often you update, the easier and cheaper it gets.

Updating is a way of reducing technical dept. Shiny new features are just a side effect of this.

Except that this is not the truth. Not only do the breaking changes make updates between these version more difficult, some of these milestone releases were just broken when it came to this or that.

First of all do agencies recognize that and have a hard time selling official versions like betas, also do some clients actually realize that the LTS versions are much more stable at all.

BTW: Please don’t mix the topic of breaking changes in minor versions with technical debts. These are two different topics that just distort each other.

I feel quite the same.

I do only use these sprint releases when kickstarting a new project. But having many breaking changes between these sprint releases, I suggest using a semantic naming scheme, that really reflects these sprint releases. Using 9.0.0-alpha1… 9.0.0-beta1 and 9.0.0, 9.0.1 and so on.
That should make clear that these versions may contain breaking changes and also results into a final release with the numer x.0.0. The suffix LTS could also be dropped in that case, just 9.0.0.
A fixed release cycle may be nice, but I’d prefer having fixed features instead.

If we introduce a breaking change to a component which gets used on a customer’s site and migrating that component is difficult, that is simply not a technical flaw that the customer is responsible for. The dev who broke the component’s API is responsible - not just for the breakage but also for providing the necessary information or even tools to perform migration. But I digress; I just wanted to inject that the above attitude is wrong imho.

What we’re discussing is really quite simple so maybe we could get back on topic:

  • Should we adopt semantic versioning?
  • Should we release public betas instead of intermediate versions; because we’re honest and saying “beta” clearly says “may break”?
  • What is more important: the years-old release schedule/roadmap or adapting to changing realities such as composer?

We have a disturbing history when it comes to releases and version numbering. Many will remember the time when releases came whenever the core team felt it was enough for a new version. Many will remember waiting for version 5.0 and only minor version numbers could be used; the jump to 6.0 and so on.
We had our first LTS release, initially to drop support for IE6 after that which became very popular because agencies seemed to like LTS versions.
During a core team meeting the idea of rolling releases was discussed. This way new features didn’t have to wait until the next major release to become usable. In short the challenges were:

  • Agencies and users like long support periods
  • Devs like to see their favourite new feature in production soon
  • The manpower for maintenance is limited

The solution was that we would release often and that each release would be stable (as stable as possible). Every once in a while (that turned out to be 18 months) there would be an LTS release that would receive bugfixes and security fixes for a long period. Because of these LTS versions we had to make sure that the collection of upgrade wizards would cover jumping from one LTS to the next one.

The LTS period was even too short for some. The ELTS concept allowed websites to use a TYPO3 for an even longer period and because it is a paid service this isn’t a burden on manpower as it allows to hire people to prepare the fixes and updates.

The fixed release dates are highly appreciated by agencies as they can plan for a project which version they will use.

Maybe we’ve been wrong with the numbering scheme. The minor versions are meant for installations that need the features. The LTS releases for websites that need the stability and don’t need the new features. This means that I would only sell a minor release if the customer eagerly needs a feature in that version. This would also mean that they need to commit to taking the following minor versions too as security fixes are only available for the latest minor.

Semantic versioning

This implies that a breaking change calls for a major version number. The result is that almost all minor versions will turn into a major version. We won’t know what number the next LTS release will have and it will be confusing for agencies and customers to understand the order of LTS versions (going from 10LTS to 15LTS is that just one LTS version jump or five?)

Public betas instead of intermediate versions

This would communicate an incorrect message. Is 9.2 unstable if we call it 9.beta2? Or is it not a beta because later there will be new features and breaking changes. So it’s all 9.alpha2, -alpha3 and so on? Then we’ve only forgotten to include the “alpha” in the version numbers…

Build numbers

Another alternative is to just use one version number or even remove that and focus on a build number for the intermediate releases. We could just use year-month-day or year-month. E.g.

  • 10 Build 170520, 10 Build 170718, … 10 LTS
  • Build 170520, Build 170718, … 10 LTS
  • 10 Build 1705, 10 Build 1707, … 10 LTS
  • Build 1705, Build 1707, … 10 LTS

Not sure if that is more understandable. Also, tools like composer would like to have versions in x.y.z format…

Release cycle

The current combination of rolling releases and LTS versions is for me a good balance between fast feature releases and LTS versions. The fixed release dates allow planning for new projects and upgrades.

Summary

  • keep current release cycle
  • make sure LTS version numbers are sequential
  • names/numbers of intermediate releases are irrelevant to me
2 Likes

First of all, thanks for the input Jigal.

The thing is, that I don’t really want to open to many threads in this topic. If we identify that the current release cycle has several issues, than it’s worth discussing the cycle itself separately.

I’d like to get back to the main thread, that is the discussion about the current minor versions and their acceptance with having breaking changes.

Devs like to see their favourite new feature in production soon

I think, this is the issue here. The rolling releases have been defined by developers, mostly. And I do miss the perspective of the ones that need to sell these releases and the clients themselves. The thing is. A good developer who has a lot of experience with the core and who is following the (breaking) changes regularly might be able to adopt a new minor version quickly. But there are a lot of agencies/freelancers that either don’t have that deep insight or who can’t keep the pace. Let’s assume you have a good dev at hand and you can actually sell a minor version because a client wants to have a new feature in production, then there are some risks to take which make the feature less valuable at that point in time. The agency/freelancer needs to check the new minor version for breaking changes in the code base of the instance. Further, all 3rd-party extensions need to be checked as well. Your client will not pay for a feature he likes when important extensions like gridelements, realurl or such are not compatible yet or do have issues with breaking changes themselves. What we do see is that minor versions are hardly used at all (in production). Thus, the headline of this topic.

How to deal with the issue is a different topic. I talked about semantic versioning as I see it as a potential solution. However, we don’t need to discuss release cycles in detail now.