Yesterday, the new ConcreteCMS version 9.2.0 has been published (
).
The previous version (9.1.3) was published 6 months before.
In the meantime, a lot of fixes have been made, and people that don’t want (or can’t or aren’t able to) install an “unstable” version have had to live with those bugs or missing features.
Is there any reason for waiting so long? What about a faster release cycle?
We do tend to get a very fast release cycle on minor point releases after a major point release 
After any new version, we also get a rush of failed upgrades in the forums. Less new versions = less frequent updating of sites = less frequent update issues.
I agree in principle for more minor point releases for bug fixes. But major point releases introducing new functionality need to be balanced against stability of live sites.
We also need to consider @andrew’s time. There is only so much jam to spread round. Even a minor point release involves a significant commitment of his time and that time may be better spent fixing further bugs or adding features rather than managing too frequent releases.
So for me, the timing of 9.2.0 is about right, but perhaps we could have had some carefully curated bug fixes earlier in a v9.1.4, v9.1.5 etc.
How about separating branches to upstream and next release? The upstream branch should accept bug fixes only, and the next release branch can accept new features.
Looking at already existing branches, it shouldn’t be conceptually difficult to have a 9.1.x branch for that sort of maintenance.
However, it’s quite a distraction to maintain such branches, and if it’s all on @andrew, I can understand why a continued maintenance of a 9.1.x branch didn’t happen, in favor of getting 9.2.0 out.
Big applause to everyone who contributed to the release of 9.2
You did an amazing job, honey.
However, I will add a bit of tar to that, because as it happens, not everything went well, and this post shows that I am not the only one who sees it.
I agree with some of @JohntheFish arguments, but we’re not here to pamper ourselves, but to push the system forward.
Minor releases don’t need to be more, but it would be nice if we knew the schedule (except urgent/safe ones - brothel fire of course 
).
If we assume 6 months* to release a major change, maybe it’s worth accepting a smaller one every 2 months?
I guess I screwed up…
Is this the right place to settle a publishing plan?
It’s not up to me/us to decide.
This is pretty much everything I agree on.
“Fewer new releases = less site updates = less update problems.”
We open our eyes less often = we see danger less often = we are less afraid.
Things that are dangerous don’t just disappear because we close our eyes, but I think I understand this unfortunate equation, and there seems to be a solution to it - do better, or at least correct known* bugs.
Nevertheless.
Since Concrete is in SAAS version it is no longer FREE.
Let’s call things what they are - PortlandLabs monetizes it - it’s good and it’s right, but …
SAAS requires on-time delivery, and that means ASAP or immediately.
I guess I’m screwed again, but I’m not making money off of this.
Either way, it would be nice if we could schedule or suspend deployments of system components that are not working properly.*
As above, kudos to everyone who contributed to this and to @andrew who pulled it all together, but we can do better.
However, I’m shocked that this whole system is based on one man and that’s why we have to wait (@andrew praises you for what you’re doing) - but maybe it’s worth delegating some tasks.
…
I just imagined it… one man and us, a whole lot of us…
Now it scares me even more and I think it should scare other users too - what are we going to do without Andy?
*exactly 6 months in version 9.x I reported problems with survey (marked as “done”) - nothing has changed - it’s actually worse. Is it worth reporting problems with the basic functionality of this system?
** Concrete CMS is also not free if you look at it the other way around.
Every person encountering errors that shouldn’t happen, trying to solve them, and finally writing a query on the forum should feel like a rightful co-author of this system.
These users more often put more time into testing than developers, often spending many hours solving or not things that would seem obvious. Here, of course, there is a lack of “mythical” documentation mentioned many times in the films.
ps. @andrew is there any chance to improve?
Since Concrete is in SAAS version it is no longer FREE.
That’s wrong.
Sure, PortlandLabs offers ConcreteCMS as a SAAS (useful if you don’t want or don’t know how to install it or maintain it).
But of course you can grab a copy of ConcreteCMS from concretecms.org or GitHub - concretecms/concretecms: Official repository for Concrete CMS development (it’s published with a MIT license, so basically everyone can do whatever they want with Concrete).
I don’t know if I understand it correctly.
As approval of my observation?
Or as disapproval?
However, the content of your statement leads me to conclude that you disagree with me (at least in part).
It’s best to get the facts in order.
This may sound brutal to some - I may even become persona non grata (probably I already am ), but it is a fact, for today this is the official position - to be clear, I respect it (even if I don’t like it) - it is an autonomous management decision.
Concrete CMS is in a release today
• FREE - do it yourself, maybe you’ll get support on the forum*.
• SAAS - Portland Labs won’t eat dinner, but your service will be rocking
This is a clearly stated issue. We may not like it, but it is.
So even if I partly disagree with you on this point - I 100% agree with your original postulate - a faster release cycle.
Regards
M
*there are quite a few posts that can illustrate this
Since Concrete is in SAAS version it is no longer FREE.
I think I misunderstood that sentence: I understood that you thought that Concrete was offered only as a paid SAAS.
Just to be clear, it’s ALSO available as a paid SAAS (and it must be paid: everyone has to be paid for their work).
But occasional visitors, reading your post, may think that Concrete is no longer free. That’s why I wrote that Concrete is free (with the very permissive MIT licence).
And that’s all I wanted to say.
I think it’s better to explain why I’m asking a faster release cycle.
I contribute to Concrete quite a lot (2105 pull requests and counting ).
The main reason I’ve submitted these changes is because I love Concrete so much that I aim to make it even more perfect.
But sometimes I really need some of these fixes/changes, and I can’t wait 6 months in order to use them, so I often end up using an “unstable” branch, or patching a stable version with composer-patcher.
That’s rather cumbersome, in particular when people I work for don’t want (or simply can’t) use a version marked as unstable.
And about the statement “Fewer new releases = less site updates = less update problems”: I’d disagree…
I think it’s much safer to have more releases with small changes than less releases with a lot of changes; in addition, if we’d have a faster release cycle we could fix the upgrades is a timely fashion.
So, I think the only problem is related to @andrew’s limited time (he’s not the only one that works on the core at PL, but he’s usually the person that creates the releases).
About that, I can of course contribute to the release process (I could create some scripts to automatize it as much as possible, for example).
I think I made it clear in the answer above that it’s FREE - and yes you’re right, the MIT license is a great deal too. I think we have a consensus.
@mlocati you are an absolute blessing to concrete cms. Where would it be without you?
Seeing all the work you have done over the years has been nothing short of amazing. Thank you for all you do!
We agree with you. Can we please get faster release cycles? 6 months was extreme. Many of the important bug fixes sat there on git for 5 months. Why?
Just talked about this briefly in the town hall but thought I’d offer more detailed thoughts. I know english is a second language for some of us, and I also know our amazing marketing efforts here coupled with crunchbase articles about how parts of the web industry work may lead to misaligned expectations. Just to be clear:
Concrete is as free as free gets. We release it under MIT instead of GPL so you can even get rid of the hand and call it your own CMS, which I know any number of companies do. (eg: Digital Experience Platform) No one pays us for this pleasure, it’s open source. That’s okay, but it doesn’t help us do more releases faster.
We have always offered hosting. We’ve got custom SLAs for large clients. We’ve got DevOps setups for webshops looking for the Pantheon.io for Concrete, and now we have quickie installs that just work for the casual site need where access to the source isn’t important. Nothing has changed strategically there beyond us offering it in a better way than a shared hosting box and instead building a platform we can use to centrally manage versions at the cost of not being able to customize code for individuals. It makes sense for Wordpress.com customers, and we needed a demo platform, so we built that ourselves. Stating that “Since Concrete is in SAAS version it is no longer FREE.” is just completely inaccurate. Hosting has always cost money, we just rarely see any of that ourselves.
It will be hard for me to believe this comes to a shock to any of the posters on this thread as I don’t believe any of you choose to host with us, but we don’t sell tremendous amounts of hosting to webshops. I totally understand why; y’all have made a business around offering hosting yourselves, and you’re all Concrete experts so you don’t really need our best practices advice. It’s a little ridiculous that we ever thought we could. A bit like selling ice in a blizzard.
Our attention to Concrete is funded by large projects we’ve closed and manage with the help of services partners. 10% of all Department of Defense web traffic is served by Concrete websites. The California Secretary of State’s website is built entirely with Concrete. Hosting and safely managing projects like this funds the vast majority of our costs, point blank. It’s not the marketplace, it’s not the brand new SaaS platform, it is our big enterprise projects. The good news for you is that means we’re not going anywhere. Unless you’re worried about the long term longevity of the U.S. Army, you don’t have to worry about our underlying attention to the core.
Now please don’t take any of the points above the wrong way. I love that we went open source in 2008, and I’m perfectly comfortable owning the weirdness of our business model. We’ve got other projects in the works that will continue to help us become more of a product company, which will eventually lead to more margin that can be spent on just doing maintenance releases of Concrete, which is a goal of ours as well. I’m not asking for anything beyond your understanding that we, like you, have only so much time in the day. While I’m super happy you’ve all picked Concrete to build your business on, at most that means we’re in this together. Your choice to use our free software and one time commission we make on occasional extension sales does not put butts in seats to do release cycles on your schedule.
Faster release cycles sound great to us too. Totally agree that waiting for simple fixes sucks. For what it’s worth, I’ve never heard a conversation like “we should wait on this release so there’s more to talk about.” We completely agree with mlocati that more releases with smaller changes would be more ideal in a perfect world. I appreciate John’s view too, but I think if the releases involved fewer changes it’d be easier to believe they would be less disruptful. Clearly this is the way software is going. Most good SaaS vendors don’t even think in terms of versions any more. Everything is CI/CD and new functionality is A/B tested weekly.
Automating our release cycle process more would be helpful. Today there’s certainly some automated steps to the process, but it is by-in-large a manual multi-step flow driven by a huge to-do list readme file. As Andrew mentioned in the town-hall there is some tooling that routinely has issues when we do a release. I know Korvin has long advocated for more automation in our release process, and I’m sure Andrew would appreciate that too. I think we need to be careful not to let ‘perfection’ be the enemy of ‘better’ in pursuing this line of thought. We’ve got a lot of 3rd party systems to touch here, so complete automation will likely be a looong way away, but that doesn’t mean a lot of value by automating parts of the release cycle. Obviously, this also would be time we’d not spend improving the core, but instead improving our systems around managing the core - so like John said… the jam has to go around.
I’d also offer that better automated testing would be a very easy way to make releases take less time and those inevitable x.1 releases to be less frequent. If you’re looking for an easy way to volunteer some time towards making it faster to release Concrete, help us by writing some tests so we have better test coverage in the core. That’s the one thing that jumps to mind where people could easily help today.
Thanks gang, totally agree faster smaller releases should be a goal.