[openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Thierry Carrez thierry at openstack.org
Fri Nov 20 10:18:19 UTC 2015


Julien Danjou wrote:
> On Thu, Nov 19 2015, Doug Hellmann wrote:
> 
>> In my mind the “independent” release model was originally meant to mean that
>> the project was completely on their own, doing potentially incorrect and random
>> releases. It wasn’t something I anticipated projects *wanting* to use. It
>> evolved to mean something closer to the opposite of the “managed” tag, but I
>> think we should pull back from that use. We want projects to clearly indicate
>> which of the other cycle-oriented models they intend to follow, and we want
>> something cycle-based for most projects to help distributors and deployers
>> understand which versions of things should be used together.
>>
>> If neither of the existing cycle-based tags meets the needs of a large number
>> of projects, then we should have a clear description of the model actually
>> being followed so we can tag the projects following it. That may mean, in this
>> case, a cycle-with-intermediary-following or something similar, to mean “we
>> have cyclical releases but they come after the cycle of most of the other
>> projects”.
> 
> Gnocchi is applying "release early, release often" so there is no really
> any big cycle like older OpenStack projects. Major or minor versions are
> released from time to time, and more often than 6 months in general.
> 
> It would be good to support that as being *normal*, not "potentially
> incorrect and random"!

It is now "normal" since it's a supported model. The issue in this
thread is more about "independent" projects which actually are following
the common cycles and therefore want to track them. I.e. projects that
picked "independent" not because they really are independent but because
they live in a grey area.

> [...]
> And by the way, it's a shame that the release:has-stable-branches cannot
> be applied for release:independent. We have stable branches in Gnocchi,
> we cannot have that tag currently for that only reason. Worse, we often
> hit issue about assumption made about how projects are released. See my
> recent thread about the devstack-gate based jobs failing for stable
> branches.
> 
> It'd be awesome to free those projects and support more flexible release
> schedule for project having a different velocity.

As I said elsewhere, the current "has-stable-branches" tag is useless
and needs to be replaced. Like you said, projects following an alternate
release cycle should be able to have "stable branches" (they just won't
be "stable/liberty" but something like "stable/2.0". What the tag should
be describing is if the stable branches follow the common stable policy,
or if they have their own rules.

So we plan to discontinue the "has-stable-branches" tag (which currently
is mostly a natural consequence of following a release:cycle-with*
model) and replace it with a "follows-stable-policy" tag that the stable
maint team would grant to compliant projects.

-- 
Thierry Carrez (ttx)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151120/0997e75b/attachment-0001.pgp>


More information about the OpenStack-dev mailing list