Release Script

[info at michael-jansen.biz]

>> The same naturally goes for stuff like kdeedu now that it split. 
>> What if
>> some application got no commits since the last minor release. Make a
>> release anyway or skip it? For major releases i guess making a 
>> package
>> anyway makes sense. Or not?
>
> Releasing all parts of the SC with the same version numbers at the 
> same time
> delivers a very clear implied message: "All of these parts are meant 
> to work
> well together" and "This is the configuration we support".
>
> Different version numbers if all of the SC is still released together 
> at the
> same time would still work here, although the "This belongs together"
> message
> is already a bit weaker.

We will always release a KDE SC Framework Version. But the parts can 
have different
versions. It is about decreasing the workload of everyone involved by 
not forcing
releases of unchanged packages. At least thats what i am talking about.

And a kdelibs hotfix (because of a security problem) does not require a 
full KDE
SC Framework release with all packages.

I will make sure we have always a up to date database about the parts 
that are supposed
to work together.

> If you decide to split up the SC into separate smaller releases, you 
> lose or
> weaken (depending on how you split) that implied message and you need 
> to
> provide this information in another way, which  means more work for 
> the
> developers to document dependencies and more work for  packagers to
> make sure
> that everything indeed is as it is supposed to be.

That is nothing i work on or plan to do. My work will make that 
possible but i currently
work on the assumption we will keep our current release practices. I am 
just trying to
script it and make necessary changes to make life easier for all 
involved.

Anything else is beyond my scope.

Mike