FabianLars
commented
4 weeks ago First things first, we realize that v2 took way too long. Our main mistake was that we announced mobile for v2 even before the v1 release without having in mind that v1 may require quite a few followup breaking changes. On the other hand, that also generated a large chunk of our hype so i guess it wasn't all bad. Either way, mistakes were made, lessons were learned. >>Subsequent major releases will be quicker and smaller.<< (that's the tldr for those who don't care)
In my eyes, a monthly schedule makes really no sense at all for a library in a semver ecosystem, at least if we consider that the webview receives updates independently from Tauri / from Tauri's major version. This alone invalidates half of your comment.
Most of our Rust dependencies can also be updated in non major tauri versions, we're also open to doing that in a technically semver breaking way for stuff like windows and webview2-com.
Then there's also the thing with our external audit approach, currently every major version is audited but that wouldn't work for more than one or maybeee two majors per year. More than that would be way too expensive and would result in not enough time for the auditors. Of course there are easy-ish solutions like only auditing every x release.
Lastly, people also generally expect some kind of LTS like support for majors.
I consider this part off-topic
Windows 7 / 8 support
Hmm yeah, i'm also one of those asking to drop support for it. But really, until now we barely had to do anything to keep Windows 7 working. Of course this will change now that all the tools stop or stopped working on/for Windows 7 but we'll see.
There are so many features that I would consider relevant enough to be developed inside Tauri Core, however your team considered it as a scope for plugins
I see where you're coming from, plugins are our alternative to more frequent major release and in general working on features in a seperate environment is, hmmm, less intimidating i guess and allows for more freedom.
to be developed in the community
Yeah, because our team is too small to do everything ourselves. Plugins tend to make it easier for community members to contribute if they don't have to understand the whole Tauri codebase (GUI frameworks are quite complicated after all)
I look into your code as a huge mountain, I believe you are great enough to deal with it. The progress has been impressive, but at the same time this delay in updating dependencies reduces predictability and the amount of opened issues is more than necessary. Tauri is a bold project, but I suspect that the complexity is far than what is needed to be. This is not a reason of incompetence. This is, in my humble suggestion, caused by other factors, among them: the lack of monthly major releases.
In my opinion, the release schedule is the most irrelevant reason for how the codebase ended up as it is now. Things like premature abstractions (tauri-runtime / tauri-runtime-wry) are in my eyes much more of a reason. Or that most of Tauri was written by a single person (even if they did a great job for such a feat).
And for the amount of issues i do agree that the v2 hurdle was probably a large contributor but at the same, the small time size probably even more so. Either way, with mobile and v2 out of the way i'm optimistic we can work through the pile better now.
Thank you for your extensive feedback. I will close this issue with this but feel free to keep the discussion going (ignoring that OP's account doesn't exist anymore lol)
ghost
Describe the problem
Tauri would serve better with monthly major releases, or in a similar expected timeframe (from 2 to 2 months, from 3 to 3 months)... Instead of yearly or longer.
This shorter, monthly cadence, is inspired by Chromium and Firefox.
Each major release does not need to offer new features. They only help in 1 thing: to alleviate the number of changes. From Tauri 1 to 2 it was a massive change. You would not even need to develop the "migrate" feature if changes were released monthly instead of packed all together.
Also, I think about deprecated functions. At the moment deprecated functions are kept in your code for years. Instead of this, deprecated functions would be marked as deprecated now, released as deprecated for example in 3.0, and in 4.0 they would be removed. This means that a deprecated function is removed only 2 months later. In a predictable timeframe. Development becomes faster for you and easier for your users to follow along the changelings and adapt slowly without being scared of updating to a major that breaks everything everywhere. The amount of breaking changes that happened late in development of 2.0 were so constant that I discarded my tauri.conf.json and started again from a blank state. For me an issue was not the amount of breaking changes. They need to come when they need to come, and we are happy for them. An issue for me was the cadence of major release, this 2.0 major release was rolling for so long. In the sense to better accommodate newer breaking changes that is intrinsic to your project, it would have been better to have finished 2.0 some time ago, just to allow more breaking changes to follow soon in 3.0.
I believe you should consider as a value/priority, that your project deals with hundreds of dependencies, and also deals directly (more than other softwares) with the specs of CSS and JavaScript. Consider that CSS spec has been developed fast, and that means that for Tauri, major releases enable you to naturally update dependencies from time to time. If not all dependencies to be updated together, at least the most relevant dependencies can then be updated monthly to their latest versions (for example: webkitgtk!!) Tauri soon gets "out of date" in this sense, when your timeframe is long enough between major releases. It is not muuuuch of a difference between webkitgtk 2.42 and 2.46, but it was already enough of a difference, since it contains more or less a year of development between these versions (I am not considering the patch releases).
See: https://github.com/tauri-apps/tauri/issues/11245
Sometimes your pull requests being proposed are simple and relevant, however due to the current long period between major releases, you end up in need to do hacks/to circumvent your code, things that only increases complexity. See: https://github.com/tauri-apps/tauri/pull/11234#issuecomment-2395107415 It would be better for yourself to avoid these accomodations in the code, and to break directly what needs to be broken. Just release it in the next major, it comes next month. See? Simple. No need for a big changelog or reason to release a major.
The mindset is different. For example, keeping webkitgtk updated would always be a priority. That is not bad in any way, actually, because it forces you to modernize little parts of your code to allow dependencies to be updated to their latest version, from time to time.
Everything is already relatively secure, I believe more than in other projects, however due to the large amount of dependencies and systems involved, I would see value too for security when not only patch versions of dependencies are at their latest, but major/minor versions too. Currently you locked some dependencies to major versions released 1 year ago. Some dependencies were even discontinued/replaced since then. This does not point to a problem at all, but to solve this, you end up generating complexity for yourselves. Because now you are going to update everything and together(!), what an amount of work. Just because a major is far to be released? When updating dependencies becomes a trivial and fast aspect of your development, less adjustments are going to be made to follow along dependencies, so things are only going to be better for you, to free your time to focus your time on actual improvements in Tauri. You won't need anymore to lock some dependencies in a past version when they don't react very well to another dependency being leveled up many numbers at once.
I would also propose for you to discard Windows 7 compatibility, and to increase minimum versions required.
If not even Microsoft releases security updates for this system anymore, if not even apps are allowed in Google's Play Store for Android versions down than number 10, I don't really see a reason why you are enabling such a large compatibility for the sake of enabling it. I mean, when I see the amount of issues, it is not rare to see issues being opened regarding edge cases in these systems, and your team is good enough to consider and try to solve these issues. But see the amount of time being used. There are so many features that I would consider relevant enough to be developed inside Tauri Core, however your team considered it as a scope for plugins or to be developed in the community. I consider old operating systems in the same way. They should not be considered anymore. Support for them can be released as plugins if someone needs it. If I am not wrong, Windows 8, windows 8.1 still receives security updates, although app releases are not accepted in Microsoft store too. In this case I would also consider to discard Tauri support for Windows 8.
I look into your code as a huge mountain, I believe you are great enough to deal with it. The progress has been impressive, but at the same time this delay in updating dependencies reduces predictability and the amount of opened issues is more than necessary. Tauri is a bold project, but I suspect that the complexity is far than what is needed to be. This is not a reason of incompetence. This is, in my humble suggestion, caused by other factors, among them: the lack of monthly major releases.
I read your blog post. I understand what is your roadmap. I believe you can fully reach your roadmap while also releasing monthly major releases from now on. You are going to span, distribute your roadmap in the multiple monthly major versions to come.
Thank your for your time reading it... I was not disrespectful in the paragraphs above, just trying to contribute... Because "when you are in the middle of the storm", I don't know if you see how much your cadence of release has not been benefitial for yourselves and for your users.
Describe the solution you'd like
Described above
Alternatives considered
No response
Additional context
No response