Release cycle / process
jsilvestre opened this issue · 2 comments
I thought about the suggested release cycle yesterday, and wondered how to actually mark something as "released". Currently it's supposed to be on the last day of a sprint, the TR tags a new version.
What about the app's build? Do we build in each PR or do we wait for the release to actually build it?
Pros:
- more accurate distinction between release and not release feature (= when users installs an app, they install upstream/master so they might end up with unreleased stuff, potentially less stable. Users can't say "I only want to have stable versions")
Cons:
- longer feedback cycle (= no simulation of a staging env if we update the app ourselves before the release to try them in real life)
While I think the "I only want to have stable versions" could be managed by the Home itself, and I believe the cons are bigger than the pros, I wanted to bring up my thoughts on the matter to the team.
Don't worry about that. Push and build on the master branch. What makes a new version is the tag on the repository.
Because it's not clean, we should install applications via npm (and make exceptions for git installations).
+1 for installation through npm, that will also allow us to publish only build folder