As raised in 1693133, I don’t think we should include grade in the template that snapcraft init produces. I’m raising it here because Leo fairly points out that this isn’t a clear cut issue.
We want to strike a good balance between a template that is typical and concise while also demonstrating that snaps are dead-simple to produce. Grade has come up in conversations with ISVs as a head scratcher.
I’ve found that the grade causes a weird workflow with continuous delivery.
When you snap a project, you will usually start with grade: devel. You set up build.snapcrat.io so it will continuously land on devel, no issues there. Then you are ready to make a release, you make a github tag for v1.0rc1, version: git takes care of setting the right version for the snap and v1.0rc1 ends up in edge automatically, all good things.
The problem is that now you can’t move v1.0rc1 to candidate because it still has grade: devel. You would have to change it to grade: stable, which means one manual step in the otherwise fully automated continuous delivery process. And let’s say you finish the v1.0 release and it’s in stable, so next you start working on unstable features for v1.1. What do you do now? Leave grade: stable even if the resulting snap is not stable? Move it back to grade: devel and return to the same problem when v1.1rc1 is read for the candidate channel?
The grade has been useful for me when I do the delivery manually. But in continuous delivery it has not. I’m +1 on removing it. Or at least finding a clever way to mark the snap as stable if there’s a git tag (which won’t work for all the cases, only for git snaps obviously).
For this reason, I wanted the version-script mechanism also to be able to set grade. Continuous integration should enable us to determine both the version and the grade, and both should be settable during an edge build appropriately. Sometimes the grade is simply a function of the branch, sometimes it’s a function of metadata on the commit, like a tag, but either way I prefer us addressing the dynamic nature of the problem than dropping the mechanism entirely.
I find it hard to believe that software developers would scratch their heads about whether a piece of software is stable or not, so if people are indeed being confused, we’re probably doing something wrong in the way we designed the feature or documented it. Dropping it from snapcraft init seems to go in the opposite direction of making it more clear, though, so -1 on it and +1 on figuring why people are confused and addressing that.
The one thing I regret about this feature but which we can still easily fix is having grade as stable/devel rather than stable/unstable. I suggest we fix that by accepting both variants and over time getting rid of devel.
Your proposal might be a step in the right direction. Another might be to make having grade set to stable and confinement to devel an invalid combination.
Yeah, I think devmode + stable grade is already a combination that is rejected by the store. We can make the tools also reject it.
The review tools do not currently flag this invalid combination-- the store’s additional checks may. I’ll fix the review tools for this.
