Release Script

[Heinz Wiesinger]

On Wednesday 27 June 2012 17:21:28 Michael Jansen wrote:
> On Monday, June 25, 2012 01:05:49 PM David Faure wrote:
> > On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote:
> > > > If we really want to decouple our releases and be more flexible with
> > > > doing
> > > > them i consider this change a requirement for any decision in that
> > > > regard.
> > > > 
> > > > 
> > > > 
> > > > Each and every module has to have its own version number build in. I
> > > > guess
> > > > with the frameworks branch much of kdelibs already got that change (no
> > > > idea
> > > > really, anyone with input?). But we have to do the same with the rest
> > > > of
> > > > our modules.
> > > 
> > > No idea about frameworks. David? Kevin?
> > 
> > This is partly still under discussion.
> > 
> > However the currently implemented solution is that each framework has a
> > versions number, but that version number can be upgraded in all frameworks
> > at the same time, using a script.
> > 
> > A future framework on top of all others, could provide the version number
> > for all apps, much like the current kdeversion.h. Basically it would be
> > the
> > "SC" number, and not the version number of the libs themselves, as is
> > currently the case.
> 
> But that SC number would be a lie. Because you only assume all modules are
> installed in the versions that were release as SC X.Y . You have no idea if
> the user or distro uses older or newer versions for some libraries, modules
> or apps. So that number has no information value. Perhaps some marketing
> value. But in bug reports it is useless.
> 
> Do we release kdelibs as ONE package. Or do we plan to release many small
> packages?
> 
> If each library gets released standalone. What if whe make the kde sc
> release 4.10.7. I assume only 70% of all libraries got commits since 4.10.6
> because stuff is pretty stable by now (7th update). Do we still release ALL
> libs or only those that got changed? Does this make a difference for our
> packagers? Does it make it more difficult or more easy? So is that a
> feature we want or not?
> 
> 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.

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.

There is also a difference if you split into frameworks, workspace and apps, or 
if you release every single tarball on its own schedule. The first is still 
well managable for both developers and packagers with regards to dependency 
documentation. The latter will just result in a big mess. Gnome and X are 
prime examples that this does not work.

Grs,
Heinz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120706/ee9d9cf7/attachment-0001.sig>