release 3.0.3

[lynxis]

The last release (3.0.2) is missing b3dc385 It would be great to do the 3.0.3 release with this fix so distributions can pick it up.

[GeraldJansen]

Under PR #656 the NEWS.md file shows that this is already included in the upcoming 3.0.3. I don't know what we can do to encourage @matthijskooijman to proceed with the release (beg, pray, cheer, ...). Only #663 was pending but it seems ready to go.

[matthijskooijman]

I don't know what we can do to encourage @matthijskooijman to proceed with the release

I'm not sure if I'm the only one who can do that, but doing the release is on my mind, I just haven't found the time yet (I'm buried in deadlines atm, which should be better in a week or two, but I'm not yet sure in what order my backlog will be processing once it does...). In any case, I haven't forgotten :-)

[lynxis]

I friendly reminder and ping for the next release.

[lynxis]

I friendly reminder and ping for the next release. @matthijskooijman

[rabin-io]

Can you please tag an release 3.0.3 ?

[ederag]

A breaking change such as #663 should not delay patch releases.

[steviehs]

I really would like to support a new release, meanwhile I had to manually apply b3dc385 as this was an annoying one :-)

[petrovo-as]

Does anyone else maintain and develop this project? I use the program every day. Thanks for the reply.

[matthijskooijman]

I'm still here :-)

When the previous maintainer resigned, four people volunteered to keep the project maintained, but then already with some reservations on available time. Of these, @mwilck, @DirkHoffmann and myself remain, but it seems available time and/or other responsibilities are getting in the way for all of us, meaning hamster is not moving much.

Having said that - I still use it myself daily and hamster development is still on my mind - I really hope to put some time in this again in the near future.

[GeraldJansen]

@aquaherd actually made the last merge, yay :-)
Any progress is much appreciated!

[petrovo-as]

Thank you for the quick reply. I just saw that no version was released in the last year. I've been looking for a time tracker for a long time and Hamster is amazing and simple. So I will send one more small problem that bothers me. :-)

[DirkHoffmann]

I never committed to doing release stuff (and previous validation, testing etc.). But if it helps, why not learn something new on github?
I may need some guidance though, @matthijskooijman.
(@GeraldJansen, I thought you had permissions to tag/release also. Am I wrong?)

I see there is a branch release-3.0.3, which diverged (2 commits ahead of master, 5 commits behind right now, but "only" release notes). Wouldn't it be appropriate to merge that first into master, @matthijskooijman?

[aquaherd]

I seem to have accidentally inherited merge rights, yes, but as your humble xfce4-hamster-plugin developer I do not know the hamster codebase good enough to even remotely assess what to merge and what not. Imagine I bring only rudimentary 2.7-ish python skills to the table.

If there was an established consent on what is to merge and what not, I would volunteer to merge even more and easily provide a tag once or twice a year.

[matthijskooijman]

@DirkHoffmann Cool! If you're going to push this forward, hopefully that will motivate me to invest a bit of time in this as well.

I see there is a branch release-3.0.3, which diverged (2 commits ahead of master, 5 commits behind right now, but "only" release notes). Wouldn't it be appropriate to merge that first into master, @matthijskooijman?

I would think it is better to just rebase that branch, maybe squash the commits in it together as well (and update it to include whatever new commits are in master now in the changelog). I created that branch mostly as a place to store a bit of release engineering work for later, I do not think the specific history of that branch is relevent and needs to be merged rather than rebased.

Furthermore, we should see if there are any other PRs ready to be merged (or important enough to be fixed and merged), but we should also probably be very conservative (i.e. not get caught up in fixing this and then ending up not releasing). I recall there were a few things I wanted to tackle, but frankly none of them is probably important enough to hold up the release.

One thing we should probably fix is #710, which I think prevents hamster from working at all on Python 3.11. I see there are (since just now) two PRs to fix this, but let's continue discussion about that in those PRs and the issue.

[DirkHoffmann]

Thanks for your feedback, @aquaherd. I think @matthijskooijman has already prepared the release with the release notes in the release-3.0.3 branch (missing probably the 5 last commits in master), and the effort for the release may be minimal
Se let's see, if he wants to pick this up in the coming days. Otherwise I will do my best to get the release out (and cleanly) in the next month.

[matthijskooijman]

If there was an established consent on what is to merge and what not, I would volunteer to merge even more and easily provide a tag once or twice a year.

Would be very welcome! There has been some discussion on policies in #585 (and somewhat related #611), and #608 about the release process.

[DirkHoffmann]

hopefully that will motivate me to invest a bit of time in this as well.

Perfect. You seem to know very well what needs to be done and how regarding the cleanup of loose ends (open branches, pending PRs). Can you take care of it then and dare to give a deadline? 😉

One thing we should probably fix is #710, which I think prevents hamster from working at all on Python 3.11. I see there are (since just now) two PRs to fix this, but let's continue discussion about that in those PRs and the issue.

Do you mean before 3.0.3 or rather after? Of course, not running on 3.11 can be considered a handicap. Looking at Fedora, it was packaged with the Fedora 37 release in November last year. In the current state of hamster, a 6 months delay can still be considered very good.
So I would favour moving those to the next release, unless they are trivial to integrate. But you decide (together with @aquaherd apparently – Thank you and welcome!).

[GeraldJansen]

@GeraldJansen, I thought you had permissions to tag/release also. Am I wrong?

@DirkHoffmann I am just a random contributor, as already discussed here: #588 (comment).

[GeraldJansen]

Please consider inclusion of PR #699, a trivial fix for a cosmetically ugly bug.

[kde-baskets-user]

DBUS API changed (twice) w/o changing VERSION - impossible to determine API version

Since 3.0.2 release at least two major API changes were committed:

• StopORRestartTracking API function was added
• UpdateFact was fixed(it was unusable before)

I believe 3.0.3 with already committed changes should be released. And after that, any API change should increment Hamster version as well for third party tools to have a chance of determining API version it deals with.

(I am working on KDE applet for Hamster)

[APCBoston]

Hey, I'm just catching up on this thread from the past couple of months but I use Hamster pretty routinely and would love to help out. I'll take a look at the issues backlog but also would encourage folks that are more familiar with it to make use of the help wanted tag :-)

[kde-baskets-user]

I am using Hamster pretty much everyday last 7 or so years tracking my entire life. I am still yet to see any close competitor in this niche both either in GNOME or KDE desktops as well. Apparent lack of maintaining is a very serious situation considering there is no easy switch to alternative even in a bigger linux landscape.

I urge people possibly willing to contribute to go through an organizational step and set up sort of discussion to clarify who can do what and is there a chance to revitalize the project. Thanks.

[salim-b]

I am still yet to see any close competitor in this niche both either in GNOME or KDE desktops as well.

For Gnome, there's Furtherance. It's simple, maintained, and very resource-efficient (thanks to being written in Rust). It also has working Gnome idle detection.

[louisdoe]

Hello
any news on a potential further maintenance ? Still stuck with Ubuntu and 3.0.2 which needs fixes.
Thanks

[matthijskooijman]

I've done a bit more work on (reviewing) some existing PR's, I'll see if I can merge some of them today or tomorrow. I do not want to merge big things that cause further delays, but I've mostly focused on either small low hanging fruit, or stuff that improves the workflow (i.e. fixes in the flatpak build or pull request flow that make it easier to test PRs and publish a build).

One remaining thing is figuring out the release flow itself (looking at #608 there might be some translation-related work that needs to happen that we have not figured out yet), and maybe see if we can automate this a bit (ideally I would say a release would consist of filling the changelog/NEWS file and making a tag, and have a github workflow generate a source tarball with the version number added and a flatpak build and upload it as release artifacts automatically).

[rhertzog]

Yet another friendly ping because we really a new release... @matthijskooijman @DirkHoffmann

I don't really understand that fear of release. Release early and often is a usual mantra and a git tag is more than enough to satisfy the need of distribution packagers like me. Not saying that it needs to be rushed, but also that you shouldn't worry of forgetting some things.... if you do people will report the issues and it will always be time to put out another bugfix release.

[DirkHoffmann]

AFAIAC, the fear is to release something, which I have not had time to test myself. But you seem to be very confident that nothing can go wrong, @rhertzog. So maybe we should make the approach with trust. Next week-end + week is a good opportunity for me to respond to this long-standing request.
Unfortunately we don't have a way to reorganise permissions as might fit, and although there is the possibility in theory to fork the complete project, there are practical issues discussed above, which make such a fork unlikely to succeed.
So I agree that the handful of actors, who accepted the permissions on this repository a couple of years ago, should use them for the benefit of the community. Maybe we can distribute the tasks among us, @matthijskooijman, @rhertzog, @mwilck, after due splitting into small pieces and some coordination and exchange?

[mwilck]

Note that I am not in the hamster maintainers group. I'm working on the GNOME extension mostly.

In general, I think we shouldn't shy away from making releases. Will there be bugs? Most certainly. Then we'll fix them and create a new release.

I believe that currently most active users of hamster are running from the release-3.0.3 branch or from the master branch anyway, so we can't do much harm by creating a release.

[matthijskooijman]

I don't really understand that fear of release.

Speaking for myself, there is (I think) no fear, just lack of time to make the last couple of steps of figuring out the proper release process, with a little bit more documentation and automation.

Motivated by recent activity, I've spent some time the last few days figuring out how to handle version numbers better, and (after some sidetracks about mismatching application ids that I've investigated but am going to ignore until after a release) I think I have a plan (basically as discussed in #608 already) that I'll try to implement in the coming days.

I think one other potentially relevant bit before release is to look at translations: Is there anything that needs to be done (manually) at release time wrt translations? Are there any updated strings or translations or whatnot that need some tooling to be run? I haven't looked at this at all, but this card suggests that there is something translation-related to be done (but also this comment that suggests that the translation stuff is not up-to-date). @DirkHoffmann is that something you might have a look at? Or maybe @mwilck, it seems you have previously (long time ago) submitted #559 which also relates to i18n work (haven't looked at it at all yet, though)?

[mwilck]

Or maybe @mwilck, it seems you have previously (long time ago) submitted #559

Indeed, a long time ago. I hardly remember ;-)

And as I said back then, it was a "rough ride". I recall that hamster's i18n code is very old and lots of it has been deprecated / replaced by different tools in the meantime. Isn't waf itself deprecated these days? My work back then was a lot of trial-and-error. I would say it can be used as groundwork for an i18n overhaul of hamster, but not more. I wouldn't recommend to do an i18n overhaul, or anything i18n related indeed, before a 3.0.3 release.

The translations are not optimal? No, they aren't. But if we wait until everything is polished, it will take another year or more until the release is out. In the meantime, people will be running hamster from git. Which is fine too of course, but then we should just announce that we don't do any releases any more.

Noone in the current team has lots of free resources to put into hamster. Therefore we should also make low-effort releases. hamster has traditionally put more effort into releases than most other projects I'm involved in. More often than not, projects just create a tag. I'm not saying that's good, but perhaps there's a middle ground between that and the complex procedure that hamster has been using in the past.

[matthijskooijman]

I wouldn't recommend to do an i18n overhaul, or anything i18n related indeed, before a 3.0.3 release.

I definitely agree that we should not do any overhaul or improvements before release. My question is mostly: Is there anything that needs to happen at release time wrt translations (i.e. something to update the translation files for changes in the code, or changes in translations to make them take effect). The answer is likely no, but I haven't looked at all, so I hope someone has :-)

So, looking at what I think needs doing before release:

• Make versioning in the code a bit more correct and simple (i.e. implement option 1 from Document & improve release process #608 (comment)). I plan to do this next. Update: Improved versioning #738
• Update waf, to allow running on modern python versions, this is nearly finished in Update WAF to version 2.0.26 #732
• Create release notes / NEWS file, a start was made in Prepare for 3.0.3 release #656, which needs to be updated using recently made git commits
• Update flatpak gnome runtime, current is outdated: flatpak: Update gnome platform #739
• Add a version number to flatpak builds (this involves renaming the metainfo.xml file - I think I know how to approach this, ignoring all other application id issues from App ids don't match #725 and will prepare a PR next). Update: Improved versioning #738
• Fix github testing/linting.
• Verify if anything i18n-related needs to be done to release (probably not).

Then, steps for the actual release:

1. Update Release 3.0.2 #609 with the complete NEWS.md file
2. Make a commit that sets the version number (maybe same commit that finalizes the NEWS file, or just the NEWS file header)
3. Tag that commit
4. Create a github release with the notes from the NEWS file, and attach the flatpak build (maybe also a source tarball? It would be just a git export, but I think having an actual tarball with a predictable checksum would be useful for the Debian package maybe, @rhertzog? Or is just exporting from git also fine)?
5. Create a new commit that removes the version number again and adds a ## Unreleased changes or so header to NEWS.md to collect changes already before release.

Ideally, steps 4 and 5 would be automated using github actions (I already have most of step 4 implemented elsewhere).

I also think it would be good to update/restructure the README a bit more to make it easier for people tot start using hamster (i.e. solve #660, but that would be fine after tagging a release (since then we also have our first versioned flatpak build available for the README to refer to).

[matthijskooijman]

I've had a look at the translations, and it seems that even though a lot of them are outdated (including the .pot files that collect translateable strings from the sources), the translated strings that are still present and applicable do work as expected (tested in the flatpak build). Also the help pages translations work.

So I think there is some work to get the process of updating the translations running again, but there does not seem to be anything needed to get a release out with what we have now.

I've created #741 for discussion on further improvements.

Edit: just noticed that since the last release, #709 added a Croatian translation, which also seems to work with flatpak run --env=LANG=hr_HR.UTF-8 org.gnome.Hamster (the PR omits the help page translations, though).

[DirkHoffmann]

Let's also update this ticket by announcing that we try to release 3.0.3 by today. I think we are almost there and took into account the most urgent requests mentioned above. Maybe someone else wants to check or give feedback on short notice?

[matthijskooijman]

It's taken way longer than it should have, but we've released 3.0.3!

Next up is updating documentation to match, and I'll try to start some discussion on plans for the next release in the coming week.

[rhertzog]

Create a github release with the notes from the NEWS file, and attach the flatpak build (maybe also a source tarball? It would be just a git export, but I think having an actual tarball with a predictable checksum would be useful for the Debian package maybe, @rhertzog? Or is just exporting from git also fine)?

The automated "git archive" export provided by Github is sufficient, there's no need to generate and store a tarball. We have tools in Debian to rebuild a bit-for-bit identical tarball from the content that we have in Git and some extra data. FTR, the pristine-tar tool provides this feature.