On 28 August 2013 16:00, Michał Górny <mgo...@gentoo.org> wrote: > Hello, all. > > I think I'm finally ready to put all the breaking awesomeness that was > waiting for the git eclasses. However, I'm wondering what's the best > way of proceeding with it. > > We've just lately finished the git->git-2 eclass migration. The old > eclass is no longer used and is marked for removal in a few days. [...] > However, I would like to do a few breaking changes to simplify > the eclass and its maintenance: [...] > But it's not all removing. There are also a few things I would like to > change/add: [...] > > How should I proceed? Assuming that git-2.eclass is used by live > ebuilds only, and those ebuilds can be subject to random breakage, > I could supposedly just start changing API of the eclass. > > On the other hand, I could also go for beautiful git-r1.eclass, > and cleanly switch the packages. > > Then, I could go for something involving the two -- create a new > git-r1.eclass that has API fully stripped, and start deprecating > features from git-2.eclass. We would be able to switch to git-r1 to > test offending packages safely, then do a big switch of remaining > packages and make the two eclasses temporarily equivalent. > > What are your thoughts?
You are planning to do more than trivial changes, so you should make a new eclass (-version). Ebuilds rely on eclass functionality to be stable, so please don't introduce unnecessary breakage. This is another indication that we really need a better mechanism for eclass versioning. But that would deserve it's own separate thread. As for naming, I recommend you do a +1 to avoid confusion, so git-3.eclass, or git-r3.eclass. Again, here it would be good to agree on a convention for everyone to follow. -- Cheers, Ben | yngwin Gentoo developer
