[Digikam-devel] Release Script News

Gilles Caulier caulier.gilles at gmail.com
Wed Aug 12 08:12:40 BST 2009


I will try it with next digiKam 1.0.0-beta4 release...

Best

Gilles Caulier

2009/8/10 Harald Sitter <apachelogger at ubuntu.com>:
> Salut everyone!
>
> For quite some time I have been working on refactoring the release
> script towards slicker design, more scalability and simpler frontend
> scripting. In case of kipi-plugins and digikam the actual script
> doesn't contain any real code at all (though that is because they use
> a shared lib ;-)).
>
> Anyway, the refactored version is available at
> https://code.edge.launchpad.net/~apachelogger/+junk/release-script-refactor
> Besides the simplified frontend code it is also a lot more dynamic
> than the previous version. While the old GUI version was dropped
> completely the new scripts now allows for cmd line arguments to be
> used (see --help for info), you can manipulate about everything that
> way. In addition to that you can also hard code stuff inside the
> scripts (see http://aplg.kollide.net/screencasts/release-refactor.ogv)
> as well as use config files... that is mostly what I meant when I said
> that the refactored version is much more dynamic. Here is the top
> reason why the refactored version is superior: it supports GIT :D
> (reference implementation available in the amarok2.rb script), it
> currently hard codes the git URL but I expect to have that implemented
> in a more dynamic manner soonish).
>
> Also checkout the README file
> http://bazaar.launchpad.net/~apachelogger/%2Bjunk/release-script-refactor/annotate/head:/README
>
> I'll probably import the refactored version into KDESDK within the
> next couple of weeks/months. At any rate you'll see a major redesign
> at some point. Especially the new Amarok structure (a combination of
> GIT [for src] and SVN [for l10n and I suppose doc]) is showing the
> limitations of the current approach, which is rather SVN centered. The
> next major iteration of the release script will come with (probably) a
> bit more complex code but should be able to scale a lot better in
> about any regard.
>
> Basically my current concept is to make the src, l10n and doc
> manipulating parts completely independent from each other. At the same
> time it will still have a kind-of gateway starting point (so the
> frontend scripts shouldn't get any more complex than they are now),
> this gateway will also act as some kind of glue between the various
> parts. All in all it should become a lot easier to enhance the
> functionality and support more VCS (the current implementation of GIT
> gives a good idea how that would be working, also since each part is
> separated from the others they can use completely different VCS). At
> this point it should be able to detach the scripts completely from the
> path structures of KDE SVN and those of extragear/playground.
>
> Well, please take a look at the refactored version and try it out...
>
> regards,
> Harald
>
> P.S. wishes and recommendations for the next iteration are very welcome
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
>



More information about the Digikam-devel mailing list