[Yum-devel] Tags, release and re-solving a few old problems

seth vidal skvidal at fedoraproject.org
Fri Oct 24 19:02:53 UTC 2008


On Fri, 2008-10-24 at 08:45 -0400, James Antill wrote:
> On Fri, 2008-10-24 at 07:46 +0200, Tim Lauridsen wrote:
> > seth vidal wrote: 
> > > I think we'll need to preserve compat with older repos for quite a
> > > while.
> > >   
> > Yes, we can add the new stuff, but we must be able to work with repos
> > missing this extra metadata.
> > both in yum and in yum-utils. me might want to implement somthing like
> > repos.findSourceRepos and repos.findDebuginfoRepos in yum base so we
> > can handle the compabillity in a central place
> 
>  Yeh, my plan was to have a YumBase().autoEnableSourceRepos() that would
> do what yumdownloader setupSourceRepos() does now, but then use the tags
> if the repos. support it.
> 
> > so each yum-utils  tool don't need to handle the compabillity.
> > > I'd hold off on putting the above changes into effect until the F11
> > > devcycle is underway.
> > >   
> > Agree, to invasive to add before the F11 dev cycle, maybe a new 3.3.X
> > branch is needed, but that leads to another discussion about
> > how we handle branches, new features etc.
> > Today we use the 3_2_X for everything, master is totally broken.
> > maybe we should rethink it.
> 
>  Yeh, Seth and I have talked about that a bit ... as we still need the
> API break, but we want to try and minimize the impact (and make sure
> master doesn't become the forgotten branch again).
> 
> > future : (yum 4.0, API breakage etc.) F12 or F13
> > unstable : (yum 3.3.x new features, but API stable) F11
> > stable : (yum 3.2.x, bug fixes, translation updates. ) F10,F9,F8
> 
>  One idea we'd had was to just continue with 3.2.x, but add all the new
> API bits in a compatible way (moving the callers as we go) ... and then
> at some point when we are happy, call it 4.0.x, merge with master and
> delete the stuff noone is using the same day and continue on with that.
> 

We could also iterate up to a 3.3->3.4. Glomming on bits as we go.

-sv




More information about the Yum-devel mailing list