A user has requested a 3.3.x (the last minor release of qBittorrent 3) snap.
I’ve created a separate branch building from that version, I’d like a 3.3.x track for qBittorrent-arnatious as well.
Cheers!
Ted
You might consider 3.3 instead of 3.3.x, but +1 from me either way.
First-time track requests follow Process for aliases, auto-connections and tracks , meaning we will have a 7-day waiting period to allow for reviewers to inspect the request and cast their votes.
The main criteria for tracks is backward-incompatibility between releases of your software, particularly if people do have a legitimate reason to want to choose an older version over the new one.
For example, if it involves invasive code changes, or has a different data format, and there’s no easy migration/conversion tool that people could use with a new release.
Can you please indicate whether this is the case with your software?
Another thing we ask for is a reasonable lifetime for releases. If you’re releasing an incompatible version every 2 weeks, tracks would be a poor fit as you would be stranding a lot of people on older releases as you move ahead. This typically indicates your software is still evolving and tracks are really best suited for mature, stable projects.
If you have a link or documentation to your project’s release schedule/cadence, that will be useful for reviewers.
Finally, you said “a user” - do you envision many users wanting to stay in 3.3.x? If it’s only for this one user, then there might be other alternatives for them to be in the old 3.3 release. I don’t have a fundamental problem with using a track to solve this, but it might be a bit overkill for a single case 
-
Daniel
-
Daniel