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