Albert Astals Cid
aacid at kde.org
Sat Jun 30 13:12:06 UTC 2012
El Dimecres, 27 de juny de 2012, a les 17:21:28, Michael Jansen va escriure:
> 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 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?
I think it makes sense to release anyway since we are using the version
numbers of SC for the tarballs (which might not be a good idea), but i would
feel confused if this happens
4.9.0 gets releases of
4.9.1 gets releases of
More information about the release-team