[rdo-list] Adding backwards compatible tripleo-heat-templates packaging

Mike Burns mburns at redhat.com
Fri Sep 9 12:29:09 UTC 2016


On Mon, Sep 5, 2016 at 10:47 AM, Javier Pena <javier.pena at redhat.com> wrote:
>
>
> ----- Original Message -----
>> On Fri, Sep 2, 2016 at 6:04 PM, Alan Pevec <apevec at redhat.com> wrote:
>> >> * A single srpm if at all possible
>> >
>> > Why is that a requirement? Usually in rpm world you create separate
>> > parallel installable compat package by adding version to the package
>> > name e.g. we had python-webob1.2 in the past.
>> > THT mitaka is 2.x so what about creating a new package
>> > openstack-tripleo-heat-templates2 ?
>>
>> We could do that and it's ok, really.  It just means a new package
>> process for every release of OpenStack.  There is no real clean
>> mapping historically of THT version to OpenStack version.  How does
>> someone know that tht2 is mitaka?  When we reach ocata and have to
>> have a BC package, it's tht5 which is newton.  (We could simply name
>> it openstack-tripleo-heat-templates-mitaka).
>
> I think something like this (having an openstack-tripleo-heat-templates-compat-mitaka package or similar) would work best.
>
> This would also allow us to decide when to drop support for older releases. Newton will have a mitaka-compat package, but we'll sure drop it in a later release, won't we? We could then just control which packages are built for each release using rdoinfo.
>
> Javier

If we do this, *every* release will drop a package and add a package.
The tripleo team won't commit to supporting more than 1 version back
currently, so -mitaka would only be included with the newton release.
In Ocata, we'd drop mitaka and add -newton.  This is part of the
reason that a single tarball made things easier.  Just get the right
source tarball for old release and build it in a single package.  An
update per release in a single spec file is generally easier than a
new package.

Mike

>>
>> The proposal currently means that we have to change 1 spec file value
>> per release rather than go through a totally new package each release.
>>
>> Mike
>>
>>
>> >
>> > Alan
>>
>> _______________________________________________
>> rdo-list mailing list
>> rdo-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
>> To unsubscribe: rdo-list-unsubscribe at redhat.com
>>




More information about the dev mailing list