Sorting out python-for-android releases

For the last few months, we’ve been mostly encouraging people to use python-for-android master. Buildozer does this by default. This has worked okay, especially for the intended purpose of bringing people up to date due to all the rapid changes, but it really isn’t a good long term plan.

Main thoughts:

• Releases should be frequent. p4a releases are actually quite straightforward (just push a new sdist to pypi and increment the version), but I’ve obviously not done a great job of doing this often.
• It’s important for p4a to have its own releases on pypi, but also buildozer needs a good way to use the latest release (and for this to also be recent code, old releases are bad).
• Until recently we did have a stable branch that buildozer used, with the idea being that all commits could be merged there once they were tested a bit on master. I think this was not a bad idea, except that we never merged nearly often enough, and once PRs got out of order it was annoying to resolve conflicts (plus I’m not sure if buildozer even behaved right when it came to updating the repo).

I’ve been wondering more recently if we should try a calver approach, with a release (say) every week. The creation and even pushing of the release package could be automated. This would have the problem that issues merged just before the release time would not be tested for long, but perhaps this could be resolved by e.g. releasing the master branch from 1 week ago, so nothing gets released for at least a week.

This would have the nice feature of a clear release trail on pypi, but also a clear ‘most recent’ target for buildozer. It would also respect that p4a is a rapidly moving project where it’s usually best to be near the top of trunk. I think it might also be an advantage that broken releases could be easily revoked if necessary (not that semantic versions couldn’t be, but it somehow seems more natural with scheduled releases), but I’m not sure about it.

Alternatively, we could reinstate the stable branch and automatically schedule merges to it. I think that would be fine, except it doesn’t give a clear set of releases for pypi. We could schedule releases on top of that, but then it’s the same as the above proposal except with an additional stable branch that only buildozer will really use.

Does anyone have any thoughts about this? All ideas welcome, the above are not strong opinions and I’m sure there could be better ideas.

[inclement]

I’ve made https://github.com/kivy/python-for-android/issues/1836 to start writing down how we actually do releases. The lack of this list is one reason I handle it so rarely, even though it’s easy to do! I intend to do one soon, alongside setting up a master/develop git flow structure, if there’s no opposition to that.

Edit: We probably should decide what we’re doing about versioning though. It could be as it is now, it could be semantic, it could be calver. I’d like to try calver probably. I don’t see any strong reason not to version as YYYY.MM.DD.

[inclement]

I noticed that we’re essentially following a ‘Github flow’ approach right now, which is mildly interesting but probably not that important.

As for the branching model, I also like the gitflow approach. All the cutting edge development happens in the develop branch and we release to master.

I would be happy to try git flow - I’m loosely familiar with the idea, but I haven’t actually followed that workflow before.

From a practical point of view, I think this would require:

• Split off a develop branch from master
• Immediately do a new release (not essential but a nice way to have a clear marker for what’s going on)
• Set the develop branch to the default

After this it seems like everyone can carry on like before, except that user stuff will get merged to develop and it’s up to us to manage releases and (if necessary) hotfixes. This seems like a fairly minor burden. What do others think?