February 2024 RCs: 28.0.3rc1, 27.1.7rc1 and 26.0.12rc1

Maintenance releases of 28.0.3, 27.1.7 and 26.0.12 are now available on our download server.

As always, help with testing is very much welcome!

We updated our servers, did our tests, and the release candidates seem pretty decent. Still, give it a whirl and report back here so we’re even more sure that it’s good to go! If you notice anything out of order, please report back on the appropriate Github repository! :bowing_woman:

Downloads

Changelogs

28.0.3 RC1

27.1.7 RC1

26.0.12 RC1

5 Likes

Thanks. The main thing I’m interested in right now is the share expiration problem. It appears a fix isn’t available right now?

Just tested with 28.0.3rc1 and the problem is still present, yet in a slighty different manner: You think you can save it to a date in the future, but you actually can’t. You will realize once you reopen the details of the share.

The subscription to external ics-calendars is also still broken.

If you want to know if a bug is fixed, check the status on the bug report at github. If they put a fix, they link the pull request that fixes the issue. This pull request then ist back-ported to other versions, click on your version, it is normally part of a milestone, the release linked to this milestone will contain the fix.

1 Like

Yes, as I understand there seem to be multiple tickets related to share expiration. Here’s one:

That one says no milestone. I’m not sure if that means nobody thinks it’s important, or maybe nobody wants to work on it. I guess my point was that if that were in the RC, then I’d definitely be testing the RC.

It’s kind of funny to add the complexity of such features, but then leave them broken. There’s another problem I have a workaround for in the security system, that I have a similar concern about. Why disallow a token form accessing files, if that breaks the files app when it’s used. Just eliminate the feature of disallowing access to files and have a functional system lol.

If you check the ticket you see that there is a pull request that was updated with last typ of information 10 hours ago.

So there is work done on it.

Thanks. That’s encouraging.

Can someone tell me how far NC 28 is ready for ‘production’ now? From what I’ve heard 28.0.0 & 28.0.1 were a bit of a dumpster fire…

You guys should really put a bit more time inbetween all those NC releases, or at least put a bit more focus on fixing, optimizing and enhancing your current set of features. Rather than, in my opinion, trying very hard to stay on edge of the latest & greatest of features the world brings us (like AI).

@StarSmasher44 wrote:

You guys should really put a bit more time in between all those NC releases, or at least put a bit more focus on fixing, optimizing and enhancing your current set of features. Rather than, in my opinion, trying very hard to stay on edge of the latest & greatest of features the world brings us (like AI).

There’s already an answer to that: use the prior (and still maintained) major that is also in the Stable release channel. The project goes to a lot of effort to maintain multiple majors at the same time so that people have options to choose: currently that’s v26/v27 (most field tested) versus v28 (latest features).

(The very post your commenting in has the changelogs for new patch releases for both v27 and v26 that are typically released simultaneously.)

If you aren’t interested in the latest features, why are you concerned about updating to the latest major? Just stick with v27 until it reaches end-of-maintenance and continue to get critical bug/security fixes there until v28 becomes the older/more field tested major. :slight_smile:

Anyhow, this is an open source project. If you want new releases of higher quality, install any of several release candidates (in a test environment or otherwise) and report any bugs. That’s the reason these RCs exist.

Or don’t do anything. That’s fine too. I gave other options above if new features aren’t your priority.

TLDR: If the latest features aren’t your priority… just keep running any older (+still maintained) major - they’re always kept up-to-date with critical bug/security fixes (until each reaches end of maintenance and the next oldest major replaces it).

2 Likes

That still doesn’t take away that NC28 was ‘released’ as a major, while having a whole bunch of issues. That was my main point.

And my original question still stands, despite your lengthy answer. Is NC28 ready now, or is is still a released, buggy mess as others have described it as?

Yes, and this discussion has already been held a zillion times here, and it doesn’t help anyone. I don’t want to sugarcoat it, but all we can do as a community is point to possible workarounds if there are any, or to GitHub issues if there aren’t any workarounds. And of course keep on stressing that people should update their production instances more conservatively, when it comes to new major releases.

About the milestones: As far as I understand it with my little knowledge about the developement process, the milestones are targeting the next major release by default. However, fixes will often get backported to the current release and if needed also to older releases that are still supported. Where and how exactly this is visible on GitHub, I don’t know, but I think it also depends on whether a backport is practical, and is therfore decided on a case-by-case basis. @jtr feel free to correct me here or add additional information about the process. :slight_smile:

I’m using NC28 in a production environment since it has been released. Yes, a few bugs here and there, but overall: no big deal for me and our users. So it always depends on how you use it and which additional apps you have installed in your environment.

Well lucky you! :smiley:

Seriously, while this is of course good to hear, it doesn’t help anyone who is running into any issues that make everyday use more difficult, and it only encourages people to continue this same old discussion. :wink:

No, of course it doesn’t… But what would help: More people running the RCs (in test environments) and reporting bugs back before the releases :+1:

1 Like

I really don’t want to blow the same horn as a lot of people here, but one thing that would probably also help, if they absolutely have to stick to the fixed release cycles, is to set the milestone for things like major frontend/UI rewrites to a release further down the road, and not necessarily to the next one :wink:

But of course you’re right, the more people who help with testing, the greater the chance that bugs will be found before a release.

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