Release Script (KF5)

[Albert Astals Cid]

El Dijous, 12 de juliol de 2012, a les 19:29:46, Michael Jansen va escriure:
> 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.

Why do you ask for opinions of you are in possession of the truth?

> 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?

That's the work of the distributor for those mobile devices.

> Do you really think splitting up kdelibs and then releasing it more or less
> as one big blog is really helpful? 

David thinks it is. I agree with him.

> Will it help people consider kde a more lightweight dependency?

Can't read people's minds.

> 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.
> Because there is no reason.

Please, next time there is no reason for something, just do it, don't ask 
people involved, complain they don't answer, and when they answer ignore them 
anyway.

Cheers,
  Albert

P.S: Is that blunt enough for you?

> 
> Mike
> 
> > Cheers,
> > 
> >   Albert
> > 
> > _______________________________________________
> > Kde-buildsystem mailing list
> > Kde-buildsystem at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-buildsystem