Release Script

[Michael Jansen]

> > So you guys have some artificial version 4.x.49.9999 which
> > downloads sources from a branch and builds them? Artificial in not
> > released by kde?
> 
> What you call an "artificial version" is a mean for us to provide the
> users who want to do it a package they can install and update whenever
> they want to track a specific branch or the head of your git
> repositories. But you're right, users will be using something that
> wasn't released by KDE. As Andreas already mentioned, these packages
> are only available on our KDE overlay and require extra work from
> users before they can use them.

Sorry that was not meant judging in any way. I wanted to make sure i 
understand if your recipes? only build hardcoded versions tested by you 
packagers and then put into the recipe regulary or if using them means living 
on the edge.

I am just trying to have a complete understanding how you release our 
software.

> We can do almost anything that can be done with bash to track your
> packages, but it will be much simpler and quicker to add support for
> packages that have reasonable and *predictable* names / versions.

> I expect that you release kate snapshot tarballs with the same name
> than the releases / pre-releases (kate).

I am a bit unsure about that sentence. Could you elaborate? When scripted the 
tarball names will be stable. 
 
  <module>-<version>

I despise releasing a snapshot or alpha/beta release as something like

4.8.80 (alpha)
or 5.80.50 (snapshot perhaps)

So i am trying to end this misuse of a normal / stable version number (x.y.z) 
for unstable releases (snapshot, alpha, beta).

A version could be

 4.8.1    (Stable: 1st update to 4.8.0)
 4.8.1.1  (Stable: Repackaged 4.8.1 - under discusssion)
 4.9.0~20120704-.... (Unstable SNAPSHOT release from the master
                      branch while developing for 4.9.0)
 4.9.0~SNAPSHOT  (shortcut to the latest SNAPSHOT for your convenience.)
 4.9.0~alpha1 (UNSTABLE alpha1 release)
 4.9.0~alpha2 (UNSTABLE alpha2 release)
 4.9.0~betal  (UNSTABLE beta1 release)
 4.9.0~beta2  (UNSTABLE beta2 release)
 4.9.0        (STABLE 4.9.0 release)

But that is not necessary. If this discussion shows it is to much hassle for 
you (or anyone else that speaks up) i won't do it.

> > So something like this (taking scotts email into account)
> > 
> > kdebase-4.8.5-20120624-<GIT ID or SVN VERSION>
> > kdebase-4.8.5-20120701-<GIT ID or SVN VERSION>
> > kdebase-4.8.5-SNAPSHOT -> kdebase-4.8.5-20120701-<GIT ID or SVN
> > VERSION>
> > 
> > would solve your problem?

You noticed me putting a symbolic link kdebase-4.8.5-SNAPSHOT there that i 
plan to update on each and every new snapshot release? So you can just 
download the snapshot over the symbolic link and be sure you got the newest 
version.

Perhaps that wasn't clear? My fault. If you still have a problem with that i 
must say i don't understand it. The filename does not get more predictable 
than that.

That semver link i gave really shows how i think versioning should be done.

Btw. That symlink means you couldn't provide your users with the possibility 
to build an older snapshot but i guess that use case is mood anyway?

> No. As I've explained in the previous email and above, using git or
> version tags force us to manually update packages and to go check each
> and every package to determine what commit id was used on the package
> name. As I've argued on the previous email, add that to a file inside
> the tarball or make that available through the package UI, but don't
> add that to the tarball name.
> 
> > Can i interpret that that you guys would get problems too if we
> > would not release all our packages with 4.9.2 . Remember we are
> > talking about leaving unchanged packages out of the release on
> > minor releases!
> 
> This will cause issues for us now. But we're willing and ready to
> update our tools if that's what will lay ahead. What we would like to
> ask is that you please think it over so that we don't have the trouble
> of updating our tools and in 1 month you rethink and reverse such a
> change.
> As Andreas already presented on his email, before you start doing
> this, we really need you to document all your dependencies for each
> package.
> The best (easiest?) way to do that would be through the cmake files or
> if you're willing to do that, to have a text file inside the tarballs
> with that info.

I am currently thinking about maintaining a special git repo that contains 
some release meta data. It will be branched in sync with kde sc releases so we 
will have KDE/4.8 and KDE/4.9 and master branches in there. It should contain 
one xml file that contains the latest released version for each package. If a 
package is added to KDE SC it will be added there and removed if it leaves KDE 
SC.

This xml file will be the main configuration for the overall release process 
too. It will containt the repos where the package is found (git or svn), the 
branch name from which the package is released and perhaps something else.

So if you want to know what makes up KDE 4.8 you clone the repo. Switch to the 
branch and look at the xml file.

Would that work?

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