El Dissabte, 21 de desembre de 2013, a les 10:32:33, David Faure va escriure: > So, we have these new repos that together make up the "KDE Frameworks". > > We'd like to release them (as a technical preview for most, as a 5.0 release > for KArchive and ThreadWeaver) this month.
KArchive doesn't seem to have any tr() call, good :-) Can I suggest removing the tr() calls in ThreadWeaver? As far as I can see they are only in setObjectName and in tests, not very useful really, so it'd be good if you can remove them and then we can say "i18n is done" since basically there's none to do :D > How should we proceed about this? Easy pasrt: tarball + repo tag. Then you need to find a place to set it up in the download server. I think we should put the stable ones in http://download.kde.org/stable/ and the others in http://download.kde.org/unstable/. But which kind of subpaths do you want? frameworks/$frameworkName/allReleasesInHere? $frameworkName/allReleasesInHere? I'd go for the first, otherwise the number of folders in the "root" is going to explode. Also you could do against the unstable/stable thing and just use stable for everything like akonadi does[1] but honestly I do think that it's not a good idea. Now, the hard part, how's versioning going to go now and in the future? I see you want to do a 5.0 of two frameworks and unstable of the others, so let's say 5.0.0 for karchive/threadweaver and 4.9.50 for the others. But what about the future? Will there be a 5.0 of the others or will skip to 5.1? If there will be a 5.0 of the others will it be 5.0.0 or 5.0.1 and then release also the karchive/threadweaver 5.0.1? I'm asking when you decide to release non beta versions of karchive/threadweaver/kconfig are they version numbers going to be in sync? Because our scripts work with the assumption that all you release has the same version number. For now the easy solution is creating two branches in that repo one for frameworks_unstable and one for frameworks_5.0, but if the versions are never going to match one would need to rethink about it. Personally I'd go for the next release that contains karchive/threadweaver + some other stable framework is 5.1, but I'm not sure what's the idea of the frameworks community around releasing all together/separate/wathever so I'd like to hear more of that since it impacts quite a bit the tooling you're going to need to do a release. > Any checklist we should follow? We kind of have three, they are the PACKAGING_HOWTO, RELEASE-CHECKLIST and RELEASE_PROMOTION files from the release-tools.git. I'd say the ones from the 4.12 branch are the most up to date. > Any packaging script (for making the actual tarball) that we can reuse for > this? You can use http://quickgit.kde.org/?p=sysadmin%2Frelease-tools.git I'd recommend the ones in the KDE/4.12 branch they are pretty simple and also should not be hard to use/understand (and i think there's even a README that explains what they do). I still don't have a script for creating a tag in the git repo since git does not allow tag creation without a clone so you'd have to use the info that is written to the versions/ folder manually. (Well actually I do have a ugly script that does the git tags and assumes I have a clone in a certain path, i guess i could try to clean it up and put it up there too if we end up deciding it makes sense for you to use these scripts) Cheers, Albert [1] http://download.kde.org/stable/akonadi/src/ > I used to know that stuff from doing the KDE 3.2 release (IIRC), but I > assume a few things might have changed since then :-) > > Cheers, _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team