[Cosmo-dev] Cosmo release frequency

[Jared Rhine]

Ted Leung wrote:
> I'd like to go back to a time based release schedule, but I'd like to 
> have people's opinions as to how frequently we ought to release.

To avoid a treatise on software development philosophy, I'll restrict my 
comments to just "Hub stakeholder".

Short release cycles are good for the Hub.

Short cycles minimize the amount of stuff that breaks at once.  Short 
cycles also minimize look-and-feel changes so that regular users aren't 
shocked as frequently.

They get features into users' hands quicker, which helps everyone guide 
("steer") subsequent development.

Ultimately, long-term Hub success is based more on features delivered in 
total; whether those features are spread of 1, 2, 4, or 30 releases per 
month actually doesn't matter that much.  It seems like there's 
consensus at least at >1 month releases are too long to "steer" properly.

I'm hearing from others that they think we'd deliver more total features 
on a monthly cycle than on a biweekly cycle, though that's contrary to 
my personal belief and experience.

I think we see a fair amount of inter-and-intragroup stalling on longer 
cycles, in particular when we need a number of RCs before final release. 
  This is my primary negative perception about month-long cycles.

If it was just about the service, I would want to look seriously into a 
real Agile deployment, see Flickr's "release every 30 minutes":

   http://blogs.warwick.ac.uk/chrismay/tag/flickr/

Related ideas include "update the Hub after each tested trunk checkin", 
"update daily", etc.  There's much in our existing processes and beliefs 
that makes such ideas a non-starter currently, but I'd push back on 
people that say it's not possible or realistic.  The blockers to such a 
route seem more philosophical than technical (ala, what must be QA'ed to 
be doing QA at all, what does it mean to produce a software release, etc.)

I don't want to oversell this Hub-centric view to the Cosmo team.  The 
final decision will be a balance of considerations and it's really 
important that the Cosmo team is happy with Cosmo development.  The Hub 
view seems to run counter to developer's stated views, so the 
owner/driver will figure out how to balance those.

Travis and I discussed over lunch some other crazier ideas.  A separate 
front-end and back-end project would allow the front-end to update on a 
faster cycle than the backend.  It would also allow the simulataneous 
production hosting of a hub.chandlerproject.org and 
beta.hub.chandlerproject.org instances pointed at the same Cosmo backend.

-- Jared