Open Stack

Sean McGinnis wrote:
>>>> Thanks for the detailed response Sean. I don't have an issue with the
>>>> cycle model - Ironic is still tied to the cyclical release model. The
>>>> part that I disagree with is the requirement to create an intermediary
>>>> release. It shouldn't be a problem if bifrost doesn't make a feature
>>>> release between Train and Ussuri, we'll just do a final Ussuri
>>>> release. It's the intermediary I'd like to be optional, rather than
>>>> the final cycle release.
>>>>
>>> I would suggest switching these to cycle-with-rc then. There is one
>>> release candidate that has to happen just before the final release for
>>> the cycle, but that's mainly to make sure everything is in good shape
>>> before we declare it done. That sounds like it might fit better with
>>> what the team wants to do here.
>> But what if we want to create a feature release mid-cycle? Some cycles
>> we do, some we don't.
>>
> With cycle-with-rc, that does allow *beta* releases to be done at any
> point during the cycle. But those would be marked as b1, b2, etc.
> releases. This allows those that want to try out upcoming features to
> grab them if they want them, but would prevent anyone else from
> accidentally picking up something before it is quite ready.
> 
> I'm guessing this might not be what you are looking for though.
> 
> We do have another release model called cycle-automatic. This was
> introduced for tempest plugins to just do a release at the end of the
> cycle to make sure there is a tag to denote the tempest version the
> plugin was originally developed for. Since some plugins are being picked
> up more often downstream, this model does allow for additional releases
> to be proposed at any point during the development cycle.
> 
> We will need to discuss this as a team to see if this makes sense for
> non-tempest plugins. It was intended only for those types of
> deliverables. I just mention it here as something that we do have in
> place that might be adapted to fit what the team needs. But we also need
> to consider what we are communicating to downstream consumers of our
> releases, so I'm not entirely sure at this point if it makes sense, or
> would be a good thing, to allow other types of deliverables to use this
> model.

Yeah the general idea was to drive toward best practices (if you do a 
single release per cycle, it's important that it's good, so it should 
use feature freeze, release candidates...). That said today it's rare 
that we break things... and nobody tests RC releases anyway.

So there is definitely a possibility for just having one single 
cycle-based release model: release once or more in a cycle, do not use 
betas or RCs. And if there is no release like two weeks before final, 
we'd cut automatically cut one from HEAD.

I'd actually prefer that to switching to cycle-independent, since 
deliverables under that model are not part of "the openstack release".

That said, it might be a bit late to roll that out for this cycle, two 
days before we actually feature-freeze cycle-with-rc projects...

-- 
Thierry Carrez (ttx)