Release Script

[Michael Jansen]

On Monday, June 25, 2012 01:16:05 AM Albert Astals Cid wrote:
> That works fine for me, though unfortunately we usually have to re-package
> some tarballs due to fixes that are needed into the release. How do you fit
> this particularity into this way of working?

With my config manager head on i say "NEVER rerelease a version". Which in our 
case includes everything that has been downloaded/used by anone not you 
(You=Packager). 

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 see one problem. As you can see the changed version information is only
> > committed AFTER build and test in this setup. That can take quite some
> > time. In a project as big as ours that opens the possibility that during
> > that time some else commits a change. Which makes it impossible for the
> > script to commits its change.
> > 
> > 1. Solution: Branch. The Script could create a branch for the release.
> 
> Creating a branch for release would also probably "fix" the problem i spoke
> in the previous paragraph

You mean the repackaging?

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.

> > 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.

> > 4. Allow the script to maintain the version increase. We have to decide
> > how
> > to solve the race condition inherent in this.
> 
> Don't understand what you mean by this.

The race condition here is the part where i talked about the script checking 
out some sources. Working for two hours (compiling, testing, packaging) and 
then wanting to commit its changes. When someone else committed something in 
that time it cannot do that on our KDE/4.x branch. The solution i prefer would 
be to create a KDE/4.x.3 branch and commit there.

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.


> In general it seems a very well though out proposal, i don't see any obvious
> problem in what you are describing.
> 
> One thing that is problematic with the current build scripts is the need of
> having up to date meinproc+kdoctools to build the packages that come after
> kdelibs, do you think that'd be an issue?

Not really. Because this script will not care. It only releases for now. The 
build-tool recipe i develop for example would take care of that. It could 
download and install the required version before going to work on the release 
packages. Like it can do with soprano, sip, pyqt4, sdo ... .

Btw. the script will only tag if you ask it too. I still remember your work-
flow of packaging stuff a week before the release date and then on release 
date only repackage stuff that got changes during that time. That has to be 
supported by the script.

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