Mark McLoughlin wrote: > That actually goes to something I'm not aware of us - the project - > having spent much time discussing. We do twice yearly releases of our > collection of software, but there are public cloud providers which want > to essentially do continuous deployment from our development branch. > > To what extent is that a reasonable thing for the project to support? If > we had a shorter release cycle, would the cloud providers switch their > deployments from continuous to the releases? If not, can the project and > cloud providers better co-ordinate somehow?
That's a discussion we had before the Essex release, when we were looking into releasing more often (every 5-8 weeks) instead of every 6 months. "What makes a release ?". After all, you will never prevent people from using milestones or random snapshots, and we should strive to make master always installable and working. So why do releases ? And what should be the cadence ? To me, releases are synchronization points. We have to have a cycle with a timeframe where development slows down at one point to let QA, documentation, integration testing and translation catch-up. A release is a point in time where the stars are all aligned. The release cycle is there to help us achieve that regularly. Those synchronization points also serve to maintain stable branches and coordinate with distros (it's no mystery that we are cadenced in a way that makes us friendly with time-based distros). Currently we can only achieve that star-aligning process every 6 months, but I hope that we'll be able to do releases more often in the future. That said, us releasing every 6 months doesn't mean we should prevent users from being able to pick a version and run with it. In particular, I think our client library release scheme shouldn't actively go against that by synchronizing too much with the core release schedule. > [...] > For argument sake, and given a 6 month cycle, say that's 2 months before > the release date. For Folsom, that's the folsom-3 milestone. > > Before that date, the project recommends that public cloud providers > deploying Folsom from our development branch does not expose any of the > new REST APIs which were added in Folsom. Assume we have provided a > mechanism (e.g. a config option) to make that possible. > > That means that we don't need a release of client libs with support for > those APIs until folsom-3. Even in this constraining setup, you keep the user vs. developer dichotomy: you want developers and early testers to actually play with your new REST APIs... so you still need two "channels": "developer" and "supported". I think Monty's solution is a way to support both in the same channel, as everyone wants to use PyPI and it supports only a single channel. My understanding is that you resist it because you think it will break during the development cycle, so releasing only when APIs to be "ready and official" is safer. What about mandating that "new REST APIs" get exposed in the client using a "experimental" or "non-final-yet" flag ? And when they get official (folsom-3 ?) we expose them to all users ? Then you could have both stable and experimental APIs live happily together... in the same PyPI channel and in the same stream of releases. > [...] > e.g. I could see us doing this: > > - When we hit essex-3, we did the first release of the client libs > which supported new REST APIs added in Essex > > - We continue adding bugfixes and new client lib features based on the > essex APIs to the master branch of the client project > > - At Essex release time, we do another release of the client libs ... > purely to co-ordinate with the project release > > - We continue doing releases as the need arises > > - At some point, new REST APIs are added in Folsom and we want the > client lib to support it. At that point, we branch off an 'essex' > branch of the lib. Support for those new REST APIs goes into > master, everything else goes into both. > > - We continue doing releases from the essex branch Alternatively, the new API could be developed in a "next" branch and merged in around folsom-3. I think that would be more consistent with how we do things, and you don't have to switch branches you release from. > - When we hit folsom-3, the REST APIs freeze and we do our first > release containing support for the new REST APIs added in Folsom The trick here is that your new REST APIs only get exposed in a published version of the client library at folsom-3, which is quite late. That would work if only end users consumed the library, and all end users would run on final releases. But our projects also use the libs to communicate between themselves. If API changes all land in F3, when does Horizon work to integrate the new featureset ? They actually need to work with experimental APIs available in the client libs as early as possible to integrate the new featureset in time for final release... So I think I still prefer the single branch model, although I'd like it to be protected with some "experimental" mode to limit the risk on end users of the latest stable release. -- Thierry Carrez (ttx) Release Manager, OpenStack _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
