How to make a new release for the stable version

[haasad]

@marc-vdm Based on your comment in https://github.com/LCA-ActivityBrowser/activity-browser/issues/750#issuecomment-1072747269 I open this issue so we can coordinate how to create a stable release and I can try to answer any questions that come up

[haasad]

I think it would make sense if we first decide on #733. Maybe take a moment to read my description of the PR, no need to understand the code itself atm, that should be safe enough to try.

[haasad]

If we go with the new release procedure then the steps are the following:

• merge #733
• Check if there are any open PRs that are ready to be included and merge them
  • personally I prefer to not directly include them in stable release but rather first try the new features in the development version (unless they're critical bug fixes)
  • rather create another stable release in a few days when the features haven been used/tested
• check the merged PRs since the last release
  • make sure they have a descriptive title (PR titles are used in the automatic Changelog with #733)
  • make sure that the PRs have one of the labels bug, feature, ui, change, documentation, breaking, ci (otherwise they won't be listed in the changelog)

And that's it basically, then all that's left to do is push a new tag on the master branch

git checkout master
git pull
git tag -a x.y.z -m "Release x.y.z"
git push origin x.y.z

where x.y.z is a new tag based on semantic versioning as discussed in #685

[haasad]

Side note; If something goes wrong it's all reversible

• delete the tag (via github ui)
• delete the release (via github ui)
• delete the faulty package on https://anaconda.org/bsteubing/activity-browser

[marc-vdm]

@haasad Thanks a lot for taking the time for this!

For #733, I'm very much in favour, making this easier is def. something we can use. The PR seems pretty clear to me in what it does, and the template could be quite helpful as well (actually, I've been think of making a template for issues too, as our userbase keeps growing, and with that, users that don't always understand how issues work or what to say/ask for help). As you mention in your comment there though. This is a 'big' change, I do think BS needs to agree on this. I'll put it on the agenda for when he's back, he probably didn't have the time yet to look at it.

For now, I think it would be good to do this release manually for the bug-fix, and hope that will be the last manual release. I had fixed the remaining issues on #750 and merged them last Fri, so from my side, the master in it's current state is ready for another release.

In general, I think AB (as a project) could do with some better organization, #733 will for sure make that easier. I'll also start looking into the milestones/projects features in GH if I have the time. We were using up to ~1yr ago but kind of lost that again.

[marc-vdm]

@haasad I want to make the new release manually because we can then finally release your bugfixes. As (AFAIK) only BS has access to the packages on the conda side, we would not be able to remove the package in case we do something wrong. Do you think we should make the new release? I already drafted the release text/message, but it seems I can't share the release draft (but here's the link anyway).

Also a question for our version management later: The semantic versioning system seems quite sensible to me, but how would that work together with our 'dev' version? If I understand correctly, it would not be possible to make bugfix releases (e.g. 2.6.x) without also releasing all features merged to master before that right? Then, we could say to just only merge features when we want to make a new release, but this would then minimize the usefulness of our dev version? Would you have suggestions on how to deal with this well?

[haasad]

I have access to the bsteubing conda channel, you can ping me if you need something removed.

I can see the release draft, looks good to me :+1: I'd say go for it.

And sorry for the late reply, pretty busy atm. I'll try give a more detailed answer to the versioning later

[marc-vdm]

Sorry, I didn't mean to rush you. Thanks for the help so far :)

[haasad]

Mhm, strange. Looks like the workflow for the stable release didn't get triggered by your release: https://github.com/LCA-ActivityBrowser/activity-browser/actions/workflows/deploy.yaml

Don't see why it wouldn't: https://github.com/LCA-ActivityBrowser/activity-browser/blob/03d46b710cb03d260ac2b82b07c3a57b1d343ea1/.github/workflows/deploy.yaml#L2-L5

[marc-vdm]

Should I delete it and redo it?

[haasad]

I'll quickly test it in my fork, I have the actions enabled there as well

[marc-vdm]

Alright thanks :) If it's not substantial work, feel free to re-do the release also, I'm not available the rest of the day. If you don't have time, also fine, then I'll do it later!

[haasad]

No idea what's going on. I don't see a reason why it should have worked for the previous releases and now doesn't. But I also don't think I've ever done a stable release for the AB myself with the current setup.

[marc-vdm]

Could it be that we (well, you, as you have access haha) have to do something manually on the conda side?

[haasad]

I just made a release again on my fork without changing anything compared to what I tried yesterday and now it works :man_shrugging: Github has had a pretty rough week with outages for github actions etc:

• https://www.githubstatus.com/history
• https://www.githubstatus.com/incidents/tyc8wpsgr2r8

Maybe we just ran into an issue on the github side. Can you delete the release and create it again? Maybe that's already enough

[haasad]

Magic :mage_man: https://github.com/LCA-ActivityBrowser/activity-browser/actions/runs/2033068299

and:

[marc-vdm]

Indeed, happy it was not our side breaking things _{for once}

[marc-vdm]

closing as taken over by #899