Hello Android teams, We, the Android Components Team, are looking at improving our release process to better accommodate our product teams. This is a Q4 goal for us, and I am sending this now to seek early feedback.
*Current Situation* First, how are we currently shipping our components? We have been doing official releases once a week, after our sprint planning. When we do a release, we publish the build artifacts to the Mozilla Maven repository and also generate the blog and documentation. Sometimes we also follow up later in the next week with a minor update to include an additional patch or fix. That patch release is more exception than rule and has only happened a few times. It has become clear that one release a week is not enough. When changes land on Android-Components, our users want to try them out sooner than later. And sometimes even ship them sooner than later in case of an urgent change. We have two ideas to work towards an improved situation. *Improvement #1 - Snapshot Builds* We plan to introduce 'snapshot' builds. A snapshot is a release that automatically follows master. So as soon as a patch lands in android-components, a snapshot release will be generated and pushed to the Mozilla Maven repository. As an app builder, instead of pulling in a specific version of a component, you would pull in a the SNAPSHOT version instead. This means that every time you upgrade your dependencies, you will get the most recent copy. (Our master branch is considered stable. So what you get is incremental stable updates - all our tests will be green for changes that land on master.) This should make it easier to stay up to date and pull in changes to the components for which you would otherwise have to wait until the official release. It allows for quicker testing and a shorter feedback loop. Do understand that these snapshots are not official releases and should not be treated as such. You should probably not ship with them since it is not clear specific version of the snapshot you get when your app gets build. *Improvement #2 - Release Candidate Builds* We have also talked about doing Release Candidate Builds. These would happen at fixed intervals in between our releases. For example, if we are currently in our 0.26 sprint, we could for ship one every other day: 0.26-rc1, 0.26-rc2 and 0.26-rc3. And then after that we ship the final 0.26 release. These are very similar to snapshot builds, except that you can pin your application to one specific build. And if you really really (really) need to, you could even ship with an RC build if you absolutely do not have the time to wait for the final release. (Again, master is considered stable). These RC builds would be automatically done on a fixed schedule. These builds would most likely just be Maven artifacts. No blog post, possibly no generated documentation. (We realize that RC is a bit misleading because new functionality could be added between builds, which is normally not the case for a release candidate - suggestions for better a name welcome.) One exception to the above, relevant to Lockbox, is the service/sync-logins component: although we do publish that component through our repository for consistency, it is not actually part of our build system. This means that changes in sync-logins will not automatically be picked up by our builds and will need some manual work to be included in a components build. Please let us know what you think of this proposal. All feedback to help us get to a final 'design' is greatly appreciated, S.
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
