[snap package] Proper release strategy.

[extraymond]

Hi! Congrats on the v3.0.1 release. @ederag

Previously, the hamster snap is build upon master for sometime, since now things are getting settled, I would like to know what would be the best way that I can help to maintain a good release story.

Snaps can track and release on multiple versions, and users will be able to switch between them if they wanted to.

---

So here's the scope that I think might cover this.

1. Channels:
   beta: tracking the latest tagged version
   stable: if beta passed all needed test, release to stable.
   edge: tracking the master branch

2. Include tests:
   If there are any tests required for a formal release, I can improve my current github action to run them so releases are nicer. I think starting from the easy one makes sense, I think pep8 and are best suitable right now since.

---

I think this will not only make users feel safer by tracking stable, but also allow developers to gather feedback on edge and beta, which might help reducing bugs. What's your though on this?

I'll start from stable: v3.0.1 and edge on master for now.

[ederag]

Thanks @extraymond, Congratulations can be extended to @GeraldJansen and many others,
including you !
It was really nice to maintain hamster with people like you around.

The new team is full of energy, so the project is fine.
They'll give their opinion on the following.

For now, the code is not pep8 compliant.
The plan was to use black soon.

Current testing was done through python3 tests/stuff_test.py.
The plan was to move to pytest after the 3.1 release.

master was usually quite stable (except in at the end of the v3 rush).
The new team also seems cautious with review and testing, so it should be the same.

So to summarize
"edge" could track master unconditionally.
"beta" could track master, after edge passes all the tests.
"stable" could track the latest tagged version.

Again, the new team will take over from here. Best wishes !

[mwilck]

What are the versions that snap uses? Is there anything else except "stable", "beta", and "edge"?

[extraymond]

What are the versions that snap uses? Is there anything else except "stable", "beta", and "edge"?

Hi! Snaps allowed submitting multiple versions into channels.
By default, there will be stable/beta/candidate/edge, and each build can be raise or downgrade to certain channel.

Other than that, some apps requires multiple versions to coexist with their own sub-versions, such as nodejs, and that can be done too. Then it will create $VERSION/$SUB_CHANNEL where $VERSION being something like v12 v13 v14, and sub_channel being stable/beta etc.

multi-channel example: nodejs snap
special off-branch: firefox snap with ESR

[extraymond]

Thanks @extraymond, Congratulations can be extended to @GeraldJansen and many others,
including you !
It was really nice to maintain hamster with people like you around.

The new team is full of energy, so the project is fine.
They'll give their opinion on the following.

For now, the code is not pep8 compliant.
The plan was to use black soon.

Current testing was done through python3 tests/stuff_test.py.
The plan was to move to pytest after the 3.1 release.

master was usually quite stable (except in at the end of the v3 rush).
The new team also seems cautious with review and testing, so it should be the same.

So to summarize
"edge" could track master unconditionally.
"beta" could track master, after edge passes all the tests.
"stable" could track the latest tagged version.

Again, the new team will take over from here. Best wishes !

That sounds fair! I'll stick it to now.

[matthijskooijman]

That indeed sounds good.

I expect releases should normally be stable (unless we tag them as beta or release candidate releases, maybe) and unless something weird happens, releases should always pass tests (even the rc or beta releases). In principle, master should also always pass all tests, but that might be easier to accidentally break every now and then.

@extraymond, I think this answers your question? Then I'll close this issue. For the matter of improving and automating the tests, as you suggested, I've created #587 to track that.

[extraymond]

Thanks! Seems good.

[mwilck]

@extraymond, my question was rather targeted towards being able to provide something like an "oldstable" release. Rationale in #579.

[extraymond]

Hi! @mwilck about #579

From what I've gathered from your comment, I believe what you propose there is a way to maintain some features from the old version, which was done before the 3.0 rewrite.

From a packager's perspective, if the old version can be build on 16.04, the oldest base snaps can be built upon, I think it's doable since all I need to do is to create a v2 version and release it on the channel.

However, I find it in a rather uneasy position, since v3 should be bringing ongoing development to the project, at least that's what made me believe this project is well and alive, if we choose to release the old version, it means that we somehow have to make sure old version is working, which seems contradict to what the current momentum is going. I believe there's also someone want to create a gnome-shell extension which would be easier to be done with newer gnome stack. I think that's something worth consider, allowing more developers onboard to create extensions and newer features would be the more happier experience one would like to engage with the project.

Since the hamster core -> dbus api and db stuff are still there, I think trying to solve the feature parity bridge without going backward would be the saner option. Just my two cents here.

[mwilck]

@extraymond, sorry if this makes you feel uneasy. Don't worry about the state of the project. Choose the version you prefer.

I was trying to figure out whether this would be an option to give users the opportunity to try and choose. I understand that snap is ususally intended to give people access to the bleeding edge. Yet basically it's "access some other version than the disto ships", so in theory, it could as well be an older version, or am I missing something?

You are right, v3 is indeed the area where development has been ongoing during the past 2 years. But a few features of hamster 2.2.2 have been lost in the transition. This is work in progress, the features may be back in future versions. To me, personally, the loss of these features is not outweighed by the improvements in v3.0.1.

The GNOME extension itself has been in a stalled state while @elbenfreund had been absent. In particular the versions on extensions.gnome.org are way behind. But the issues the extension had with recent GNOME version updates have been resolved. Working code for all current GNOME versions can be obtained from the various open PRs on github, and will be merged very soon.

[extraymond]

@mwilck No biggie, I totally understand your proposal. Just that I from my perspective, app development these days seems quite different then the time hamser v2 was created. So my motivation for this project would be different than yours.

People relied more on mobile devices and web platforms now, with mobile linux devices maturing (pinephone/plasma/ubuntu touch), I can see a bright future for hamster, since nothing is quite as handy as hamster even after all these years.

If I remember correctly, the whole v3 rewrite was under the goal of separating the core and front-end, so as long as the platform provides a way to communicate with hamster via dbus, chances are extensions/utilities are a reachable goal. Therefore I'm more biased toward the new version then the old one and am quite excited for ongoing development. Sometime ago, I even tried communicating with hamster via dbus under rust/qml and it seems working.

---

Before jumping toward any resolution, I think it would better to start documenting the dbus interface first, and see what's cause the feature parity you experienced. Maybe it might not be too hard to get it back. I tried using the typing module on hamster and found quite some type bugs, but not sure if that's inline with the project's goal, since most of the python ecosystem tend to not use type hints. What do you think we can make this work more reliably? Currently I think api-docs and type tests are the closest target.