What to release from where?
Maciej Mrozowski
reavertm at gmail.com
Tue Jun 21 19:29:42 CEST 2011
On Tuesday 21 of June 2011 02:46:13 Frederik Schwarzer wrote:
> Hi,
>
> because of all the trouble the moving migration caused so far,
> As of now, Dirk had to ask before every release, what he should release
> from where.
> I thought it might be a good idea to make things more ... written-down.
>
> http://techbase.kde.org/Projects/MovetoGit/Progress
>
> I hope I got the current status correctly. If not, feel free to comment
> here, make changes directly or hit me on IRC (icwiener).
>
> What I am especially interested in is feedback from you, Dirk,
> on how helpful this might be if properly maintained.
Excellent, thanks!
A small question to release-team here (and repo maintainers), would it be
doable to have the same branch names for all packages released under "KDE SC"
umbrella?
Currently, while KDE/${major}.${minor} is obviously the most popular one,
variations exist. I believe it doesn't help from packager point of view wrt
scripting the process - and certainly makes things a bit more complex from
distro packager point of view (hunting down all branching/tagging variants
from all project repos,
Sure it applies mostly to distros that track code from repositories - not just
when tarballs are released - which is minority I believe.
"${major}.${minor}" branch names can be also confusing (for newcomers but
still) in case of apps that provide own versioning as well, for instance
Okular in 4.6 branch reports itself as Okular 0.12.4, analogy with Marble
(randomly picked examples here, no strings attached).
Adding 'KDE/' prefix to branch names would without doubt denote that this
particular branch is to be used for fetching and tagging for KDE SC
distribution (when certain application is released so probably tagged
individually as well).
I understand however that consistency on this field and on tag names imposes
certain "KDE workflow" (to "natively" use KDE/${major}.${minor} branch names)
on apps that aim to "sell themselves on their own" or involves more merging
work otherwise (but hey. branches are cheap in git).
Btw, how did it happen that svn -> git move caused so much dispersion in
branch names? (tagging fortunately is more or less consistent, thanks to Dirk
most likely).
--
regards
MM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20110621/fceb4f86/attachment.sig
More information about the release-team
mailing list