info at michael-jansen.biz
Wed Jun 27 15:21:28 UTC 2012
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
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the release-team