(Sorry sent too early) El Dissabte, 30 de juny de 2012, a les 15:12:06, Albert Astals Cid va escriure: > 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 > > 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?
Speaking in the apps side (not frameworks) 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 kalgebra-4.9.0.tar.xz ktuberling-4.9.0.tar.xz okular-4.9.0.tar.xz 4.9.1 gets releases of okular-4.9.1.tar.xz 4.9.2 gets releases of kalgebra-4.9.2.tar.xz ktuberling-4.9.2.tar.xz okular-4.9.1.tar.xz As a user i'd think, what happened to kalgebra-4.9.1.tar.xz and ktuberling-4.9.1.tar.xz ? On the other hand we might want to use the *real* version of the application and not of the SC, then it might make sense to skip if no changes happen. Cheers, Albert _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
