Axel Thimm wrote : > > > o should yum 2.2 perhaps become yum3 and be also called that way to > > > indicate the major change and allow coexitence with yum 2.0.x w/o > > > renaming yum 2.0.x? > > > > no. > > Why? And is this "no, no" or "<no answer>, no"? ;) Well, just "no, yum 2.2 won't become 3.0" is my guess. > I think bumping the version to 3.0 is more than justified (especially > in relation to yum 1.x vs 2.x). Future distinction will be easier to > make in yum 1, 2 and 3 eras. Just s/3/2.2/ and you're done. > > > I am mainly thinking of the current yum repos that have yum 2.0.x > > > clients deployed and will be migrating to the new metadata format, > > > and will want to have a (rather) smooth transition (e.g. offer both > > > formats and both clients and allow a grace period for the users to > > > switch). > > > > yum-arch is available in yum 2.1.9 and above. > > I am not really concerned on the server-side, but more on the > client-side. For example today's FC2 repos (or even RH7.3 repos like > Fedora Legacy) may want to switch to the new metadata format. Offering > both metadata formats on the server is not a real issue, but offering > both clients for a transition period will be due to common naming. It > would be nice to find a common way to deal with it (e.g. renaming yum > 2.0.x to yum-2.0). I really don't see any issues, other than users needing to notify repository administrators to modify their scripts to also generate the new common metadata. BTW, why would you want to offer _both_ clients? Once yum 2.2 goes final and gets well tested, people should start using it instead, and any bugs reported against it should get fixed (which is better than getting advice like "switch back to yum 2.0.x"), and we'll all live happily ever after. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2.91 (FC3 Test 2) - Linux kernel 2.6.8-1.607.radeon Load : 3.87 4.07 3.90
