Yes, it fails to deal with several types of release versions, e.g. fedora.us pre-release versioning scheme and macros in the release tag.
ah, I didn't realize.
> If you want to do them by hand that's fine by me. I'm not sure what > we're disagreeing about. Do you want to do a mass rebuild as a test now? I want to avoid [more] chaos if that's possible, please.
What's chaotic right now?
We have the FC-3-split in CVS now, but how do we proceed? Every commit to FC-3 branch moves "devel" more out-of-sync.
yes, that's the same that happens with fedora core.
It is not clear to me what you have planned. Do you want every individual package owner to bump release versions in current "devel" tree on some day between now and FC4T1?
I didn't have much of anything planned. We wanted the branch for extras so people could work on new versions of changed build deps due to fc4. The goal was to make extras cvs match core cvs so that people could follow 'development' sanely.
At fedora.us we've had mass-rebuilds for the first or second test release, and the dist tag made a release bump unnecessary.
Right but if you read the packaging guidelines, I'm not sure we're quite there yet for those bits of infrastructure.
In Fedora Extras, this is the first time we branch in CVS, and we need a concept.
The concept is simple - give a place to start from and to start merging to. When fc-4 gets finally branched in core cvs then we should branch fc-4 in extras as well and 'devel' becomes the new location for:
1. the fedora extras development repository
2. the new work for fc5
Then the FC-4 branch in extras becomes where you merge changes for FC-4 extras packages to.
FC-3 for FC-3 extras package changes.
etc
etc
etc.
thats the the structure that I think was intended. So extras matches how core is developed.
does that make sense to you?
-sv
