On Thursday 12 July 2012, Michael Jansen wrote: > On Thursday, July 12, 2012 07:21:40 PM Albert Astals Cid wrote: > > El Dijous, 12 de juliol de 2012, a les 13:26:12, David Faure va escriure: > > > 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? > > > > > > Many small packages, but all at the same time. So "based on KDE > > > Frameworks 5.0.1" will have some value in bug reports. > > > > > > However you're right, apps themselves should have their own version > > > number, > > > maybe we can solve the same way as we do for the frameworks: by running > > > a script that updates the toplevel CMakeLists.txt in all modules > > > before releasing. > > > > > > > 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? > > > > > > All libs, obviously. Who would take the time to run a diff and make > > > really sure that nothing changed? This is additional work for nothing > > > and makes everything more complex. Just like right now, we release > > > kdeadmin or kdetoys with every KDE SC release, even if nothing > > > changed. > > > > > > > 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 can't decide there, that's for the release team to decide, but IMHO > > > if it's all scripted and done all at once (KDE SC release), then it's > > > simpler to just re-release everything. > > > > I agree with David here, just release everything, it's easier for > > everyone. > > No it is not. It is a waste of bandwidth, resources and time for all > involved. > > Do you really think forcing an update of unchanged modules for our > convenience will help those of us trying to use plasma for mobile devices? > > Do you really think splitting up kdelibs and then releasing it more or less > as one big blog is really helpful? Will it help people consider kde a more > lightweight dependency? > > I will implement the ability to skip release for unchanged modules (fully > automated) and would ask everyone here to really think twice before asking > the release team to keep the current practice of releasing everything.
I think I mostly agree. It sounds like the correct thing to do. I'm aware that this may somewhat contradict my posts to the versioning discussions on kde-frameworks... But basically, if a library has not changed, I agree that it's version number should also not change. Still all can be released again, so you can get everything at once if you need. Alex
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
