[oe] Discussion: Version retention policy in oe-core

[Tom Rini]

On 03/15/2011 06:14 AM, Philip Balister wrote:
> On 03/14/2011 07:13 PM, Tom Rini wrote:
>> On 03/14/2011 03:22 PM, Philip Balister wrote:
>>> On 03/14/2011 11:58 AM, Tom Rini wrote:
>>>> Hi all,
>>>>
>>>> The TSC has discussed this item at the request of the community and has
>>>> come up with the following recommendation which we are looking for
>>>> feedback (positive/negative/neutral) before putting this up on the
>>>> wiki.
>>>
>>> Looks reasonable. One thing I did not see is asking people not to add a
>>> new recipe and delete the old one in separate commits. This makes it
>>> easier to figure out problems when they arise.
>>
>> So, part of what is envisioned here is that for, grabbing a recent
>> example, nodejs 0.4.0 to 0.4.2 we just see a git mv, and that's the
>> normal case for that level of things. But for say 0.4.9 to 0.5.0 (or
>> would it be 0.6.0? I don't track the project, but next stable release
>> that's not in 0.4.x) it would be add 0.5.0 one commit, drop 0.4.9 the
>> next, Does this still fit, given your comment?
>
> The immediate case I am thinking off is the policykit-gnome update.
> (Which I think did the add/delete in the same commit). One of the
> changes was a configure option change that led to build failures on my
> F14 box. I'm not sure how this fits in the scheme you describe since the
> versioning seems to lack a major/minor concept. (Well the minor number
> is large)

So, policykit-gnome was just adding a new stable version (as default). 
The previous one is still there (in part because of pinning of 
dependencies to older versions).

Plugging this example into the workflow:
- policykit/policykit-gnome have newer stable versions released.
- Add new version as default, test[1]
- Keep old versions for now due to some distributions pinning glib-2.0 
to an older version that policykit > 0.98 (or so) need.

And, that brings us to [1].  FC14 seems to show off a class of bugs that 
need squashing.  I'd love it if someone can point me at a VMware 
compatible image (with functional tools) already installed.  That said, 
I think I meant to post to the ML and forgot, or no one saw the 
EXTRA_OECONF bug in the recipe that Koen fixed which I think fixes your 
problem.

> In a perfect world, what you are describing is great, however I'm
> concerned the "special cases" may be an issue.

The special cases being the critical infrastructure?  Or the unclear 
version policy?

-- 
Tom Rini
Mentor Graphics Corporation