Release Script (KF5)

[Albert Astals Cid]

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.

Cheers,
  Albert