Release Script

[Michael Jansen]

> I do not disagree here, BUT have in mind that since we have private packages
> (used/tested by distro packagers before the release actually happens) so
> YOU is a broad term including the packagers.
> 
> > For KDE would say someone else should decide. We could make a release
> > 4.8.80.1 if we have to repackage stuff. But the packagers distros should
> > give input here. I think they should say what is the easiest for them to
> > handle.
> 
> I'm sure having a micro release is going to break their scripts that just
> expect 3 numbers.

I really would like to have some input of real packagers here. I am inclined 
to say if noone speaks up now they have to live with whatever we come up 
afterwards. I am not caring for people who only complain after stuff is done 
when they kept silent while it was discussed and designed.

INPUT guys. NOW.

> > I am btw. wondering that noone objected yet to this. I seem to remember
> > someone was unhappy about dirk branching some 4.8.x release. I don't
> > remember where and why.
> 
> No, Dirk didn't branch any release, he created a 4.8.x branch, which doesn't
> make sense since KDE/4.8 branch is exactly that.

OK.

> 
> What i'm saying is create a 4.8.80 branch where we can cherry-pick the
> needed fixes for re-packaging 4.8.80 because right now this can happen
> 
> Imagine the 4.10 Beta 1 release in a few months, current behaviour would be
>  * Package 4.9.80 from master branch
>  * People keep adding fixes and whatnot to master
>  * You realize there's some compile problem in platform X
>  * You need to repackage 4.9.80 to include the fix, but since you have no
> 4.9.80 branch you have two options:
>    - Update wholesale to the mater branch including not only the fix but all
> the other commits too
>    - Manually include the fix in the tarball, making git tagging impossible
> since there's no hash commit anymore with the contents you are releasing
> 
> If we create a 4.9.80 branch this issue is fixed, since you cherry-pick
> there and re-create the tarball.

Exactly what i had in mind. The only thing left to decide is the name of the 
recreated tarball.

> > > > 2. Solution: Lock the repo (A no go in my opinion)
> > > 
> > > Yeah, locking kills babies
> > > 
> > > > And a little problem. The feasability of beeing able to build our
> > > > software
> > > > before packaging. I already have a solution to build the packages with
> > > > build- tool as a test. But no idea yet how to combine build-tool with
> > > > this
> > > > script unless i add this into build-tool. And the admins would like to
> > > > have
> > > > python. Not ruby. And build-tool would not mash with the idea to use
> > > > jenkins to trigger the releases.
> > > 
> > > "this script" == maven?
> > 
> > I will not use maven. I just steal some workflow there. This script is the
> > script which we currently try to hammer out how it should work.
> 
> Not sure I see the problem then, can't you just invoke build-tool from the
> script that you/us are creating?

I hope so. There will be some need for twisting and matching. Because build-
tool has a different use case. But since i have quite some experience now with 
doing that kind of scripts i can probably come up with a poor mans build-tool 
in python that has the minimum features required.

	- Build everything in the right order
	- Build just one module
	- Keep logfiles in a central place
     - Maintain the environment so the actual build-machine does not matter.
     - Work over problems and record a overall state at the end.

> > But that probably breaks
> > 
> > ~/ws/src/KDE/kdelibs : git describe
> > v4.8.90-26-g1dd5c9d
> > 
> > Which i personally do not care about. I won't stop doing the right thing
> > because it is inconvenient.
> 
> I'm not a git knowledgeable person, what would exactly break and why?


AFAIK that reports how far away you are from the last tag. I have no idea if 
this jumps over branches following merges or if the tag HAS TO BE in the 
straight history of your current version.

The example given means i am on a version that is a successor of v4.8.90. I 
have exactly 26 commits on top of that. The 'g' is for git and the rest the 
commit id.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120703/015d81e8/attachment-0001.html>