search

thsmi / sieve

Sieve Script Editor
GNU Affero General Public License v3.0
763 stars 59 forks source link

New release? #925

Closed polarathene closed 9 months ago

polarathene commented 9 months ago

https://github.com/thsmi/sieve/blob/5879679ed8d16a34af760ee56bfec16a1a322b4e/README.md?plain=1#L70-L74

Last release there was Nov 2021: https://github.com/thsmi/sieve/releases

https://github.com/thsmi/sieve/blob/5879679ed8d16a34af760ee56bfec16a1a322b4e/README.md?plain=1#L79-L86

Has the project changed to relying on this approach instead of proper releases like was previously done?

Just raising an issue as the advice seems either outdated with the preferred release process, or there is some reason that releases stopped being published to GH Releases for over 2 years? (I've seen the roadmap on the wiki, but it doesn't clarify why releases have ceased, nor does other wiki pages that provide guidance on nightly builds)

thsmi commented 9 months ago

Don't see why it should be outdated by any means. What is a release good for when there are no changes? Just look at the commits, not much development or fixing has happened much in the last two years.

The Thunderbird WebExtension is still broken, before it is fixed it does not make sense to publish a new release. And for the application there are no major changes worth investing the time into a release. The time is better invested into fixing todos.

polarathene commented 9 months ago

What is a release good for when there are no changes?

You have plenty of worthwhile changes?

Nothing ground breaking sure, some are features that are niche but useful to have, while changes that benefit a broader audience are mostly from upstream (but also this one from you + the i18n updates)

Upstream changes (that exist in nightly builds)

Your own project code might not have changes, but dependencies may?

https://github.com/thsmi/sieve/blob/5879679ed8d16a34af760ee56bfec16a1a322b4e/.azure/linux.yml#L13-L18

JS packages + NodeJS are more than likely to have at the very least patch releases since the last published project release, which can contain fixes including the kind that address security.

If you've updated to major/minor versions since, those can result in other improvements. Sure for this project that's perhaps minor and any known concerns requiring updates would probably be requested 🤷‍♂️ (I can't keep on top of all the security issues and general fixes personally, but there's rarely any harm in pulling in updates for patch releases, or major/minor if you've already done that since in master)

https://github.com/thsmi/sieve/blob/5879679ed8d16a34af760ee56bfec16a1a322b4e/.azure/linux.yml#L54-L61

Likewise for AppImage.

And and obvious one with Electron compare:

https://github.com/thsmi/sieve/blob/5879679ed8d16a34af760ee56bfec16a1a322b4e/package.json#L13-L14

https://github.com/thsmi/sieve/blob/360dac066910668b5c5f493d1036bc79daf17a7b/package.json#L13-L14

Examples:

PipeWire obviously isn't relevant to this project, I'm not going to sift through everything that's changed upstream since, but I think you understand the point being made. Your current builds are using newer dependencies since the last official release, you've done so for a reason, there's value in that.

Changes within the project

Just look at the commits, not much development or fixing has happened much in the last two years.

Notably this issue comment where you admit the problem is resolved with newer dependency updates (electron), and users requested a new release in April 2023 but ignored:

The electron in the release is rather old and has known incompatibilities with some graphics card drivers. Which is fixed in newer releases, thus I updated the dependencies.

Would be nice to see this Oct 2023 PR considered too, but for whatever reason you're not engaging with the contribution?

Then you also have translation updates which can benefit various users, but they must rely on nightly CI build artifacts, despite the README advice pointing to official releases where unaware users will miss out on those improvements.

If you don't consider what I've covered here as sufficient to justify a release that'd benefit your users... then please consider updating your README + wiki to encourage users to prefer the nightly builds.

Maybe even link the reader to this comment for why they may be interested in the Azure builds vs Nov 2021 release, and communicate that you don't plan to make a new release for many more years if that's the case?

The Thunderbird WebExtension is still broken, before it is fixed it does not make sense to publish a new release. And for the application there are no major changes worth investing the time into a release. The time is better invested into fixing todos.

That's fine, but if it's still broken after over 2 years, and I assume low priority to you, how likely will that remain the case? May be better just to highlight that it's broken (I've not checked to see if the existing Nov 2021 release is fine, but assume it is).

I'm not familiar with your release process and how much time that takes, no worries. Nor am I familiar with what important TODOs you want to address. In my experience though these never really stop, which puts a future release in limbo as it's been already.

If you're already lacking time for the project though which appears to be the case, especially since as you point out not that many changes have really landed since Nov 2021.... I don't really follow the reasoning to avoid a release when the pace of resolving those blocker concerns doesn't seem like it's making much progress at all. A release may be easier and more valuable to users in that sense 🤷‍♂️

thsmi commented 9 months ago

What sense does it make, to encourage users to use untested code?

The app is currently in an very stable state. As you can nicely see in the commits you listed there are very few bugs and all of them are mostly rather exotic corner cases. The blank-page issue is a very good example for this. I happens only on very few system in very special constellations.

And honestly I completely don't understand why listing development resource like the yaml build files or node.js or electron packager should be of any benefit for a user? It is only used during development to package the application and is neither shipped nor of any use for a shipped release.

The app uses only a fraction of the electron code base and all the electron dependencies. Just look at the electron changes you listed client side decoration in Wayland or screen casting. The first one will be most likely not even recognized by most of the users and the second one I highly doubt that there is a real world use-case. Nothing which would be by any means groundbreaking or critical.

There are also are no known security flaw which affect any code used by the app. It is constantly scanned for this. Yes there are dependencies with well known issues, but the code is not used. If there are no security updates, no features or bug-fixes, it is pointless to update the dependencies just for the cause of releasing a version with updated dependencies. But in contrast a dependency updates can and does introduce new bugs and issues. This is why I do update whenever I start coding to get an impression about which bugs are introduced by the dependency update and need to get fixed. But as said such fixed don't offer any benefit to any user. And releasing them untested does not make any sense.

Concerning the readme.md it clearly states if you want something stable use the official releases. They are known to be stable. And in case you run into any issues or want to experiment then try a continuous build.

So I really don't get why you insisting to have releases just for the purpose of having releases. It just burns time, slows down development and does not offer any benefit to a user. I do releases whenever there is a noteworthy feature, bugfix or security update. None of which is currently true as you listed extensively in you post.

polarathene commented 9 months ago

TL;DR: We have different opinions, neither of us are likely to shift on that. Agree to disagree? 😅

The blank-page issue is a very good example for this. I happens only on very few system in very special constellations.

I've experienced this type of bug in other electron apps, took a year or two before someone fixed it. It was quite easy for me to reproduce and report in a way that others could reproduce it too. Perhaps the users that experience often just don't report it 🤷‍♂️

Assuming it's the same bug, I would likely encounter it too and have to use the nightly for the fix.

What sense does it make, to encourage users to use untested code?

At what point do you decide it's ok for a release and you don't have this same concern?

It's been over 2 years since your last release and you have stated that there is nothing major changed in the project code or the dependencies to warrant a release, yet you have this concern? How will that be any different once you have your "noteworthy" feature/fix/security update?

If you do have a major security issue to address in future, and you resolve that, are you going to publish a release promptly, or will you have blockers like this concern, especially since it'd have comparatively less time for testing a rushed change (especially since you've already established your limited time resources). Or as an added bonus you throw in the growing time since your last stable release towards this concern of untested code...

Release more often, even for the small things and you minimize this concern. It's not like your users can't rollback to earlier releases if there is an issue that is reported and needs to be fixed, in the meantime you update the release page for the affected release to communicate the problem if it's a serious one. It's a common practice 🤷‍♂️

And honestly I completely don't understand why listing development resource like the yaml build files or node.js or electron packager should be of any benefit for a user? It is only used during development to package the application and is neither shipped nor of any use for a shipped release.

A misunderstanding on my part then. I thought your app was published as an electron app using node.js packages. That can be meaningful to the user if it were the case, but you're saying neither are involved (I haven't gone so far as to check that), then no worries 👍

The first one will be most likely not even recognized by most of the users and the second one I highly doubt that there is a real world use-case. Nothing which would be by any means groundbreaking or critical.

Well... that just made the previous paragraph redundant. In that case I referenced those snippets to show that it was tied to the published release..

As I said when I linked those examples, I was not going to go digging through 2 years+ of changes that fix/improve user experience but I'm sure there's plenty (most likely with Wayland support). I'd still expect improvements that are relevant regardless of what your app does itself.

So I really don't get why you insisting to have releases just for the purpose of having releases. It just burns time, slows down development and does not offer any benefit to a user.

I've tried to communicate the reasons, which you disagree with. It's your project, proceed as you see fit. I don't see it as costly to time or slowing down development for projects I manage, changelog is updated with each PR and CI automates the rest.

All I've said is:

Apparently that's asking to much and is just insisting on a release for the sake of it? Only because you don't agree with it being of any value in your opinion, and the massive burden you attribute towards publishing a release 🤷‍♂️

I do releases whenever there is a noteworthy feature, bugfix or security update. None of which is currently true as you listed extensively in you post.

You say that, but also state blockers that deter you from producing a release. So I'm a bit doubtful and would see you downplay any concerns / requests raised to avoid it.

Sorry for the sour tone in my response, I get the impression that it doesn't matter what points I make to support a new release for your users. If you're not interested, it's just not going to happen, not much point wasting our time debating that further 😅

Concerning the readme.md it clearly states if you want something stable use the official releases. They are known to be stable. And in case you run into any issues or want to experiment then try a continuous build.

The concern was that part of the README had been like that for about 2 years, and it seemed odd that there was development since then with no new release made or planned.

You've already responded here to clarify why:

Since no new release is on the horizon due to your limited time, and you don't plan on producing a new release despite multiple requests in the past by your own users.... Just update the README to clarify that no new releases are planned, the existing Nov 2021 stable release is still considered ok, but future releases are via CI only.

Nothing wrong with communicating that builds are now only managed/supported via CI. I can't imagine you are still supporting the Nov 2021 release, since any bug report may have already been reported but no release will be made officially, you've made that clear here.

I do understand and relate to your concerns with having limited time available to work on OSS, I hope the discussion provided some actionable value for you (even if that's just a README update). I didn't mean to waste your time further 😞

dxdxdt commented 7 months ago

Oh I'm seeing a potential fork!

reivilibre commented 2 months ago

I hit the blank page issue 100% every time, have tried clearing the app's storage and anything I can think of. A friend of mine can reproduce it most times. I'm not sure what is so special about our systems that causes this :)

If a release is too much hassle just for that bugfix (which I do understand), I'd be very happy to try a CI build, but it looks like the CI builds for the latest version may have been removed as they expired?

(Am I just missing the right place to look?)

polarathene commented 2 months ago

(Am I just missing the right place to look?)

Not AFAIK, seems something went wrong with their setup, or as you suggested probably expired.

There's no history of nightly runs available and the badges also aren't looking healthy.

image

image

No commits for over 6 months, so that's probably not a surprise.

Problems:

One might hope that'd justify pushing out a release. All that's required is building one (perhaps via the CI pipeline if that's easiest), potentially tagging it in git, and then releasing on Github Releases as a -beta.

The developer may not be comfortable with a -beta release, but it minimizes any additional burden they'd likely have as expressed above regarding friction for putting out a release. A beta release at least provides a build that is available without the CI problem that now exists.

Probably best to update the README after that to convey the status of the project. Sometimes we just don't have the time we'd like to spare on our projects, I've ceased development on some of my own ones that had a community, it happens and that's ok.

polarathene commented 2 months ago

The CI build issue was a problem since April: https://github.com/thsmi/sieve/issues/931#issuecomment-2132279050

@thsmi was only recently active this year (commit wise) in August. They hadn't responded to that linked issue, so I'm pinging in an attempt to get their attention (they might not be subscribed to updates on this repo anymore, or just busy or swamped with notifications that they missed the issue).