Update ways of working #5722
Update ways of working #5722
Conversation
|
@ln @grzesiek2010 I'm going to have a think about the Transfix stuff referenced in the description, but it'd be great to get feedback on the changes here. |
|
Looks good to me! The only thing that surprised me is that https://github.com/orgs/getodk/projects/9 is private. May I make it public? |
Absolutely! I'd actually meant to request that as a comment here and then forgot. I'm unable to change visibility for org projects 🤷♂️ |
| * [CI](https://app.circleci.com/pipelines/github/getodk/collect) is currently failing | ||
|
|
||
| If a PR is being merged to a release branch rather than `master`, any strings added as part of the changes should also be added to `master` (with `tools:ignore="UnusedResources"`) as a follow-up PR so that they can be translated. |
There was a problem hiding this comment.
There's definitely smoother workflows, but they all require a high degree of non trivial automation so let's go with this for the moment.
README.md
Outdated
|
|
||
| Once the majority of high risk or visible work is done for a release, a new beta will then be released to the Play Store by [@lognaturel](https://github.com/lognaturel) and that will be used for regression testing by [@getodk/testers](https://github.com/orgs/getodk/teams/testers). If any problems are found, the release is blocked until we can merge fixes. Regression testing should continue on the original beta build (rather than a new one with fixes) unless problems block the rest of testing. Once the process is complete, [@lognaturel](https://github.com/lognaturel) pushes the releases to the Play Store following [these instructions](#creating-signed-releases-for-google-play-store). | ||
|
|
||
| Fixes to a previous release should be merged to a "release" branch (`v2023.2.x` for example) so as to leave `master` available for the current releases work. If hotfix changes are needed in the current release as well then these can be merged in as a PR after hotfix releases (generally easiest as a single PR for the whole hotfix release). This approach can also be used if work for the next release starts before the current one is out - the next release continues on `master` while the release is on a release branch. |
There was a problem hiding this comment.
for the current releases work should this be plural? I know that it's possible that we work on more than one release on the same time like now for example be usually it should be one.
There was a problem hiding this comment.
I think best to think of just one "current" release for master. As you say, what we're doing now is the exception.
There was a problem hiding this comment.
So you agree it shouldn't be plural?
There was a problem hiding this comment.
Ah it should be release's. I've fixed it.
seadowg
force-pushed
the
ways-of-working
branch
from
8b960dc
to
a593f80
Compare
An update to our
README.mdandCONTRIBUTING.mdto reflect the way we've been working for the last couple of releases. It felt like a good point to write this down for ourselves, and for any external contributors looking to get involved.I think as part of this PR, we should also update our Transifex/strings workflow so it works better with release branching. Currently, we run into problems because we only get translations for
masterwhich means that the translations might not be appropriate even present for a different release branch.